Blitz renders HTML and CSS without carrying a whole browser
Blitz is a set of Rust crates for applications that want web-style documents or interfaces without Chromium or a complete web platform. The high-level blitz wrapper renders HTML and Markdown but currently has no interactivity. dioxus-native takes a Dioxus VirtualDom and adds event handling. Beneath them, separate crates handle DOM state, HTML parsing, resource loading, layout, paint commands, windows, menus, and accessibility. Teams can use the wrapper or assemble only the layers they need.
Our commit aa41c30 checkout contained 366 files, about 55,047 source lines, and occupied 7.3 MB. The dependency installation finished in 83 seconds and recorded 1 installed package in the harness. That small checkout makes the engine approachable as source, though graphical examples still pull together Winit, AccessKit, Vello or another renderer, HTTP support, Stylo for CSS, Taffy for box layout, and Parley for text. Modularity reduces coupling; it does not remove those moving parts.
The reduced scope is a product decision
The project aims to support modern layout, complex selectors, media queries, CSS variables, form controls, accessibility, and custom widgets. It does not intend to bundle WebRTC, WebSockets, Bluetooth, localStorage, and every other browser feature by default. In a native app, the maintainers expect ordinary Rust crates to provide much of that functionality. This is a sensible boundary for a renderer embedded in a controlled application.
It is a poor boundary for arbitrary web content. JavaScript support remains in the roadmap backlog, along with C bindings and other language bindings. The 10-second build in our environment does not change that compatibility picture. A website that depends on client-side rendering, storage, browser extensions, video, or a full DOM API will need another engine. Blitz is easier to evaluate when the application owns the markup and can restrict its component set.
What happened when we ran it
Our sandbox installed the Rust project in 83 seconds and built it successfully in 10 seconds. The test command ran for 341 seconds and exited successfully, yet Cargo reported 0 passed, 0 failed, and 0 total. A green exit with no cases is compilation work, not behavioral evidence that pages render correctly.
The repository scan found 4 CI workflow files, no Dockerfile, and a tests directory. Our run used an unprivileged Debian container with 3 CPUs and 12 GB of RAM. It did not open the browser UI, draw a page, compare screenshots, test input, or measure accessibility output. We also measured no startup time, frame rate, memory use, or standards coverage. Those would require a graphical harness and representative documents rather than extrapolation from a 10-second build.
Fixed and absolute boxes can land in the wrong place
Issue #764 reports that absolute and fixed elements resolve against their DOM parent's flow position instead of the correct containing block or viewport. In one minimal case, a fixed box expected at coordinates 0,0 appeared at 8,16 because of the default body margin and flow position. Another case placed an absolute child at 45,6 instead of 15,5. Headers, tooltips, menus, and overlays are exactly the elements that rely on this behavior.
The roadmap still lists static and fixed positioning under the work toward 1.0, while active pull requests are changing out-of-flow hoisting and stacking-context behavior. That is healthy engineering activity, but it also means layout internals are moving. Use screenshot comparisons for every supported viewport and interaction state. Our 341-second zero-test result cannot stand in for those visual regressions, particularly when a current issue demonstrates coordinate errors in ordinary CSS.
A failed stylesheet request can leave the window blank
Issue #694 describes a network failure path where the resource handler is dropped without a callback. If the missing resource is a render-blocking stylesheet, its identifier remains in the set of pending critical resources, and painting stays blocked forever. Browsers ordinarily treat a failed stylesheet as loaded with no rules and continue. An embedded UI needs the same failure policy or a bad URL can become a permanently empty window.
This is more serious than an unsupported CSS property because it prevents fallback content from appearing. A production wrapper should add timeouts, surface resource failures, and exercise offline or 404 cases until the upstream path is fixed. Blitz networking is optional, so applications with their own resource provider also need to ensure every request completes with success or error. A silent drop is unsafe for any item that can block first paint.
Beta is accurate despite daily development
GitHub showed 4,069 stars, a dual Apache-2.0 and MIT license, and 173 combined issues and pull requests. The repository was pushed on August 26, 2026. GitHub returned no latest release object, while the README labels the engine beta and the roadmap tracks a 0.3 beta milestone before 1.0. The open queue includes selector work, tables, stacking contexts, SVG, font settings, pictures, and JavaScript compatibility tests.
Blitz has a coherent reason to exist: controlled native applications often need HTML and CSS layout, not an entire browser. Its crate boundaries and 10-second build make architectural evaluation easy. Its browser-compatibility gaps and absent discovered tests make production approval harder. Start with a fixed set of application screens, add pixel and accessibility baselines, simulate failed resources, and pin the exact Git revision. If the input is the public web rather than your own markup, use a broader engine.