Blitz: A lightweight, modular, extensible web renderer

Original Article ↗ Hacker News Discussion ↗

Primary goals and positioning

  • Blitz is a lightweight, modular HTML/CSS renderer written in Rust, intended as a “webview without JS” and a foundation for native app UIs.
  • Aims to be an alternative to Electron / full browsers for:
    • Application UIs
    • High‑fidelity markdown preview
    • Embedding web-style content into other systems
  • Design emphasizes modularity: pluggable render backends, optional features (SVG, AVIF, networking, floats, etc.), and reusable components (e.g. the Taffy layout engine).

Current capabilities and limitations

  • Not production‑ready yet. Noted gaps:
    • Only basic text input and focus handling.
    • No scrolling beyond the root viewport.
    • Complex CSS selectors (e.g. nth-child, :has) are buggy.
    • Event handling is rudimentary (mostly clicks; no preventDefault).
    • Networking is synchronous on the main thread.
    • Performance is “currently terrible”: style/layout/paint recomputed every frame; known memory leaks.
    • Missing features: shadows, web fonts, calc(), float layout, most form controls.
  • Developers expect a more complete state in a few months.

Performance and footprint

  • Intent is not necessarily to beat Chromium overall, but to be much smaller and more customizable.
  • Compared to Servo/WebKit:
    • Blitz reuses some Servo components but avoids its tightly coupled JS/GC architecture.
    • Servo is ~100 MB; Blitz is ~20 MB now, possibly ~3.5 MB with aggressive optimization.

PDF, screenshots, and non‑browser use

  • Many commenters want a wkhtmltopdf/Chromium‑free path for:
    • PDF report generation.
    • Server‑side rendering and screenshots.
  • Blitz currently lacks JS, so some doubt its usefulness for screenshotting modern JS‑heavy sites and worry about incomplete CSS causing visual mismatches.
  • Headless image rendering was added experimentally; PDF support is not implemented but seen as feasible and rising in priority. Collaboration with an existing PDF‑focused project and SVG→PDF workflows are mentioned as related ideas.

Accessibility

  • Thread highlights that many modern GUI toolkits neglect accessibility.
  • Blitz already exposes an accessibility tree and keyboard focus via a cross‑platform abstraction layer; more work is planned, but accessibility is explicitly on the roadmap.

Ecosystem, integrations, and alternatives

  • Positioned closer to Sciter than Tauri (own renderer vs system webviews), but with a focus on better modern CSS (flexbox/grid, variables, media queries).
  • Some interest in:
    • Bindings for languages like Python and C++.
    • Porting or natively supporting HTMX‑like behavior without JS.
    • Using Blitz as a base for custom document formats or alternative layout models.

Wider web‑stack and CSS discussion

  • Several comments criticize HTML/CSS complexity and dream of simpler document or UI formats; others argue HTML/CSS’s ubiquity and semantics are major advantages.
  • Blitz’s modularity is seen as a possible testbed for new layout algorithms or even new markup-on-top-of-CSS approaches.
  • There is interest in stricter/simpler CSS subsets, but others note that most of CSS exists for real use cases (especially document-style layouts), so “removing cruft” is nontrivial.

Naming and perception

  • One commenter questions the name “Blitz” due to WWII associations; others respond that the term is widely used in modern English with neutral “speed” connotations.