rakers — a headless JS renderer in Rust

tbxyz — Tue, 19 May 2026 20:17:57 +0000

A lot of useful content on the web only exists after JavaScript runs. Server-side rendering has made a comeback, but plenty of sites still ship a near-empty HTML skeleton and populate it entirely client-side. If you want to extract that content — for archiving, testing, or processing — you need to run the JavaScript first.

The standard answer is a headless browser: Playwright, Puppeteer, or a self-hosted Chrome. These work, but they are heavy. Chrome's footprint is around 300 MB, startup takes one to two seconds, and running it in CI requires care. For many use cases the full browser is overkill: you don't need CSS layout, GPU compositing, or WebGL. You just need the DOM to exist after the scripts have run.

rakers is an attempt to find the floor on that problem. It is a single ~10 MB binary that parses HTML, runs the JavaScript, and returns the post-execution HTML.
How it works

The pipeline has three stages:

Parse — html5ever (Servo's HTML5 parser, published as a standalone crate) turns the input into a DOM tree.
Execute — <script> tags are collected in document order, inline and external alike. External scripts are fetched synchronously. All scripts are evaluated in a sandboxed JS context that exposes a browser-compatible global environment: document, window, console, XMLHttpRequest, localStorage, setTimeout, and more.
Serialize — The post-execution DOM is serialized back to HTML and written to stdout (or a file).

The JS engine is QuickJS via the rquickjs crate. QuickJS is ES2023, compact, and embeds cleanly into Rust without much ceremony. For environments without a C compiler there is an optional boa_engine backend, a pure-Rust JS engine with a smaller compatibility surface but zero native dependencies.
The DOM stub

The trickiest part is not the JS engine — it is the fake browser environment. Frameworks like React, Vue, and Svelte expect a fairly complete DOM API. Since rakers has no real layout engine, those APIs are implemented as a JavaScript stub in bootstrap.js that is injected before any page script runs.

The stub covers the most common patterns: element creation and mutation, getElementById, querySelector, querySelectorAll, event listener registration, classList, localStorage, history.pushState, and XHR. XHR is backed by a synchronous Rust fetch (ureq) so frameworks that load templates at runtime via XHR — like RiotJS — actually retrieve them.

Inevitably there are gaps. Anything that requires layout information (offsetWidth, getBoundingClientRect) returns zero. Native ES modules are skipped. The stub is good enough to run 21 of the 23 TodoMVC implementations, which provides a reasonable compatibility benchmark across React, Vue, Angular, Svelte, Preact, Mithril, Elm, Backbone, Ember, Knockout, and others.
Using it

Render a URL

rakers https://example.com

Render a local file

rakers page.html

Pipe HTML in

curl -s https://example.com | rakers

Route traffic through Tor

rakers --proxy socks5://127.0.0.1:9050 https://example.com

Filter to a CSS selector

rakers --selector "article.post" https://example.com

Installation instructions in the README.

What it is not

rakers is not a browser. It has no CSS engine, no layout, no WebGL, no IndexedDB, no service workers. Anything that depends on those will not work. Sites that fingerprint the JS environment or require a real navigator.plugins array will also fail. For those cases a real headless browser is the right tool.

The value proposition is narrow but real: for sites that render via a self-contained JS bundle with no exotic browser dependencies, rakers is faster, smaller, and simpler to deploy than anything that ships a copy of Chromium.

A learning experience with NetworkManager and zbus

tbxyz — Sun, 29 Jun 2025 14:16:31 +0000

Traveling heavily recently, I've become fatigued from typing all the WiFi passphrases. My phone can happily connect via a QR code. Why does my laptop required so much typing, I asked. So I proposed a simple project.

Researching how I might use my web-cam to connect to WiFi networks, I came across the Network Manager and Rust's Zbus article on rbs.io. I use NewtworkManager and I enjoy working with rust. I know next to nothing about DBus, but I thought some knowledge of hacking Linux networks couldn't do me any harm. Besides I had some free time.

The above article set me on the right path. The zbus documentation is still a little obscure in some salient details, however. Hopefully this post will help fill those in. The finished code is hosted in the scampi repo.

I first needed to generate a settings.rs with zbus-xmlgen as described in the above article. It is straightforward to create a connection by building the nested structures of HashMaps also described there. While that solution works, it is tedious, unsightly and doesn't make the most of rust's type system. Finding the issue for using DeserializeStruct with nested structs closed, I hoped there might now be a more ergonomic way forward.

With the help of the zbus book I managed to piece together a solution that feels a little more rust-like. Of course there are many pieces to the puzzle. You need serde and the zvariant::Type macro. But all that is gleaned fairly easily from the documentation, I think. The more salient discovery was that zbus allows declaring DBbus signatures on your types. This is done via a macro, like so:

#[zvariant(signature = "a{sa{sv}}")]`
struct MyType{..}

Declaring the correct signature(a{sa{sv}}) on the struct passed to NetworkManager's Settings.add_connection() allowed it to navigate Dbus's type system. Its children don't have any children of their own, so SerializedDict and DeserializeDict works fine on them.

For a more complete example you can have a look at the code.

I believe I could go further and replace some fields defined as String with more appropriate types, but it's one more thing to learn and I think this is good enough for now.

Originally published in my blog.

DEV Community: tbxyz