He shadows a whole website into one runnable binary — and the README is the controversy
Point Kage at a site, and headless Chrome renders every page, strips all JavaScript, then packs the lot into a single executable you double-click offline. Half the thread argued whether the AI-written README means the code is slop too.
Kage drives headless Chrome to render a page the way a human sees it, snapshots the settled DOM, deletes every script, downloads CSS, images and fonts locally, then bundles the mirror into a standalone binary or a ZIM archive.
The first reply pointed to SingleFile, which packs a page into one self-contained HTML file with no server needed. A security researcher caught Chrome launched with --no-sandbox; others called the README LLM slop and assumed the code was too.
A website you can email as one file, scripts and all stripped out

Kage (404 points, 91 comments) is a Go tool that does what wget --mirror cannot: it archives sites that only render through JavaScript. The pipeline is deliberate. Headless Chrome loads a page and waits for it to settle, the DOM is snapshotted as a human would see it, every script is then stripped out, and CSS, images and fonts are downloaded to local paths with links rewritten. kage clone <url> crawls with depth and page limits; kage serve runs a local HTTP server over the folder; kage pack compresses the mirror into a ZIM archive (readable by Kiwix) or a self-contained binary that serves the site with no dependencies.
The positioning is offline reading: clone paulgraham.com, carry it onto a flight. That framing set the whole thread arguing about whether this is new, whether it is safe, and whether a website belongs inside an executable at all.
"Isn't this just wget, or SingleFile, or curl?"
The comparisons came fast. The top reply put forward a sharper-looking alternative:
"I find SingleFile to be a much more robust version of this. It strips out all the JavaScript too, but also packs everything into a single HTML file… Binary assets… are packed as base64 strings." — a commenter pointing to gildas-lormeau/SingleFile
Others reached for older tools: httrack, pandoc-to-EPUB for e-readers, wget --mirror. One reply was just "curl can do this." The author's own README anticipates the JavaScript gap, and rahimnathwani (15k karma) landed the cleanest one-line summary of where Kage actually differs:
"So this is like using wget --mirror except that it works on pages that require javascript, right?"
That is the real distinction. wget copies bytes; Kage runs the page first, then freezes the result.
The recurring question: why does a static mirror need a server?
Several readers tripped on the same thing. If the output is static, why kage serve instead of just opening the file?
"If the result is static why does it need a server? Isn't it possible to make it so that it can simply be opened by the browser?" — a commenter who wants it to work on machines without kage installed
A founder echoed the wish for a serverless shim — "a single HTML entrypoint… that could index into an archive of the site's content." The binary-as-website packaging drew open hostility from one corner: "No one would ever want to run a binary shared with them or found online." A Windows user confirmed the friction in practice — Windows Security flagged the bundled leakless.exe as a virus.
A security researcher catches --no-sandbox
The most useful technical note came from the founder of a Swiss security firm:
"you launch Chrome with --no-sandbox. Is there a good reason for that? Security wise it's probably not a good idea." — dimiprasakis, founder of Minoan Security
A founding member of the Czechoslovak video game archive wanted the opposite extreme — archive-grade fidelity by pairing Kage with mitmproxy to save the exact bytes served alongside the rendered view, as a WARC replacement. And Simon Willison went spelunking through the repo, discovering the README's demo GIF was generated by yet another of the author's projects, an ascii-gif wrapper around charmbracelet/vhs.
The README became the verdict on the code
The sharpest reversal had nothing to do with crawling. Multiple high-karma readers refused to evaluate the tool on its merits because of how its README reads:
"The readme is AI slop, and incredibly grating to read. The disgust I felt while reading it almost put me off trying the project. Is the code also AI slop?" — a commenter on the README's tone
"The README is LLM slop. This makes me assume the code is the same." — sneak, 25k karma
That is the quiet lesson here. A genuinely clever tool — render-then-freeze archiving that wget can't do — got a chunk of its top thread spent on whether a machine-written README poisons trust in the whole project. The crawler is the easy part. In 2026, the README is now a credibility surface, and a tool that nails the hard engineering can still lose the room on prose.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
A solo dev built an ER diagram tool that never sends your SQL anywhere — then a data engineer said it isn't ER
Paste your CREATE TABLE statements, drag the tables around, rename a column and the SQL rewrites itself — all in the browser, nothing uploaded. A senior data engineer politely pointed out that SQL alone can't actually produce a true ER diagram.