htmx 4.0 Ships on Game Boy Before It Ships on npm

A library that fits in a <script> tag hit the Hacker News front page this week for shipping on hardware from 1989. The htmx swag store is selling "htmx 4: the game," billed as "the first JavaScript library to release exclusively on the Game Boy® platform" — and unlike most joke merch, the cartridge actually works. It's a real, playable platformer: four levels of pickle-collecting, a final boss named Warren Buffering, and, if you win, the htmx 4.0 source code scrolling across your Game Boy's screen.

It would be easy to file this under "htmx does memes again" and move on. That would miss both halves of the story. The stunt is funnier than it looks, and the release it's satirizing — the real htmx 4.0 — is a more consequential rewrite than most people running htmx in production have clocked.

Yes, it's a real Game Boy game

Per creator Carson Gross's comments on the HN thread, the game was built by Stephen Mitchell in GB Studio — the open-source drag-and-drop Game Boy dev tool — with custom modifications, then pressed onto physical cartridges and handed out free at Big Sky DevCon. The swag store now sells it to everyone else for about CA$36. There's no emulator download, no web port. If you want this particular distribution of htmx 4.0, you need a Game Boy.

That's the joke working on two levels. htmx's whole pitch is that the browser is already a capable hypermedia client and you don't need a compiler toolchain to build for it. Shipping the source code locked behind a boss fight on a 4 MHz handheld is the most htmx way possible to needle an ecosystem where "install the framework" routinely means 300 MB of node_modules. The library's actual distribution remains what it's always been: one dependency-free file.

It's also marketing that money can't easily buy. htmx has no venture backing and no growth team; its funding is sponsorships, a book, and a swag store. What it has instead is a creator who understands developer attention better than most DevRel departments. The "CEO of htmx" bit, the self-deprecating essays, and now a physical cartridge — each one costs almost nothing and lands the library on the front page again. For a project competing for mindshare against React's institutional gravity, the meme pipeline is load-bearing infrastructure, and it's been working for five years.

The real 4.0 is the bigger deal

Behind the cartridge, htmx 4.0 exists and is six betas deep as of late July 2026, with the latest prerelease landing days before the Game Boy stunt hit HN. (There's no htmx 3.0 — Gross publicly promised there would never be one, so the major after 2.0 is 4.0. The man keeps his commitments in the most literal way available.)

Gross has called the release "The fetch()ening": the internals drop XMLHttpRequest for fetch(), a rebuild informed by his minimalist fixi.js experiment. But the transport swap isn't the change that will touch your templates. This one is: attribute inheritance becomes opt-in. In htmx 1.0 and 2.0, attributes like hx-target and hx-confirm cascade implicitly to child elements, CSS-style — behavior Gross now calls the biggest mistake of those versions, and he's right. Anyone who's debugged a button inheriting a hx-swap from a wrapper div three layers up knows the failure mode. In 4.0 you say what you mean:

<!-- htmx 2.0: children silently inherit the target -->
<div hx-target="#output">...</div>

<!-- htmx 4.0: inheritance is explicit -->
<div hx-target:inherited="#output">...</div>

The other changes follow the same de-magicking instinct. History support stops snapshotting the DOM into local storage — a chronic source of stale-state bugs and accidental sensitive-data caching — and instead re-fetches from the server, with the old behavior available as an extension. Server-sent events and streaming move into core rather than living as extensions. Morph-style swaps (morphInner, morphOuter) arrive in the box, which means many teams can drop the idiomorph extension. Event names get a stable, predictable grammar, which matters because htmx's event system is its real extension API.

What to actually do about it

If you're running htmx 2.x in production: nothing, yet, and possibly nothing ever. Gross has committed to supporting htmx 2.0 in perpetuity, the same deal 1.0 and intercooler.js got. That promise is the most underrated feature htmx ships. In an ecosystem where a major version bump routinely means a migration quarter — ask anyone who lived through a React Router or Next.js app-directory transition — "your current version is supported forever, upgrade when the new one earns it" is a genuinely different social contract with your dependencies.

If you're starting something new, the calculus is closer. The betas have been iterating fast, which is what betas are for, but it also means the original "early-to-mid 2026" GA target has slid; treat 4.0 as late-2026-at-the-earliest for anything you can't babysit. For a greenfield app that leans on SSE or streaming responses, building against the 4.0 beta and eating the event-name churn is defensible. For everything else, ship on 2.0.9 and do the one cheap piece of prep that pays off either way: stop relying on implicit attribute inheritance now. Put hx-* attributes on the elements that use them. Your 2.0 code gets easier to read, and your eventual 4.0 diff gets close to mechanical.

The Game Boy cartridge will sell out, get scalped on eBay, and be forgotten by October. The inheritance change will still be saving people debugging time in 2030. But it says something good about htmx that the silliest JavaScript story of the summer is a marketing gag wrapped around the most disciplined major-version rollout in front-end right now: breaking changes that fix admitted mistakes, escape hatches for every removal, and no forced march off the old version. More libraries should be this unserious about marketing and this serious about everything else.