HTMX 4.0 swaps XHR for fetch and adds a reactivity layer, but keeps 2.x on latest until 2027

HTMX 4.0 is the first major version of the hypermedia library since it became a fixture of the server-rendered revival, and it rebuilds the engine underneath without changing what htmx is for. The headline is a swap from the aging XMLHttpRequest object to the modern fetch API, but the release also promotes DOM morphing into the core story, adds an optional reactivity layer, and turns off the implicit attribute inheritance that has shaped how htmx apps are written for years. None of it forces your hand today: the team is keeping 2.x on npm’s latest tag and says it will support that line indefinitely.

The engine swap is the quiet headline

Replacing XHR with fetch sounds like plumbing, and for most existing apps the change is meant to be transparent. The payoff is what fetch unlocks. htmx can now stream a response and process HTML fragments as they arrive instead of buffering a whole reply before swapping, which InfoWorld’s Matthew Tyson singles out as the most fundamental advance in the release. He frames it as the rare upgrade that “actually reduces your JavaScript footprint and makes the architecture simpler,” and htmx still ships at roughly its familiar 14KB. For a working developer, the practical effect is that progressive rendering, long the reason teams reached for a heavier framework, becomes achievable inside the hypermedia model you already have.

The other structural move is bringing the idiomorph algorithm into the core swap story. Morphing compares the old and new DOM and mutates only what changed, rather than replacing a whole subtree, so form state, focus, and third-party widgets survive an update. Pairing that with streaming is the combination that closes much of the gap between htmx and the SPA experience, without asking you to adopt a client-side router or a virtual DOM.

hx-live is htmx answering the reactivity question

The most notable addition is hx-live, an extension that adds what the team calls DOM-based, HATEOAS-friendly reactivity. In plain terms, it lets you bind small pieces of client state without leaving the hypermedia approach or reaching for a separate library. It draws openly on Alpine.js and hyperscript, and it reads as htmx’s answer to the recurring criticism that server-driven apps still need a sprinkle of client-side interactivity that htmx alone did not cover. Keeping it an opt-in extension rather than folding it into the core is the right call: it addresses the gap for teams that feel it, and stays out of the way for the many that pair htmx with Alpine and do not want a second reactivity model.

Where the migration cost actually lands

The breaking changes are honest about their cost. The biggest is attribute inheritance: in 2.x, an attribute like hx-target cascaded to child elements implicitly, and in 4.0 you opt in per attribute with an :inherited modifier. That is a deliberate reversal the team argues is safer and clearer, and InfoWorld reads it as a pragmatic refinement drawn from real-world experience rather than a technical necessity. Event names also move to a consistent htmx:phase:action shape, HTTP error responses now swap by default where 2.x ignored them, and the old localStorage history cache is gone in favor of refetching on back navigation, which plays better with third-party scripts.

For teams with a large htmx codebase, an upgrade-check CLI flags what needs changing, and a htmx-2-compat shim restores the old inheritance, event names, and error behavior during a transition. The signal that matters most, though, is the npm plan: latest stays on 2.x and 4.x ships under next until early 2027, specifically so that unversioned CDN links do not drag anyone onto a breaking release unattended. Combined with an open-ended support commitment for 2.x, that turns 4.0 from an upgrade you race to complete into one you schedule when the streaming and morphing wins are worth the inheritance rewrite.

What it means

HTMX 4.0 is a rebuild that stays true to the library’s argument: less client-side machinery, closer to the platform, HTML over the wire. The fetch-driven streaming and core morphing are the reasons to move, hx-live is a considered answer to the one thing htmx skeptics kept naming, and the inheritance change is the price. The versioning discipline is the tell that this is a project thinking in decades, not release cycles. For most teams the move is to read the migration guide now, pilot 4.0 on a single flow behind the compat shim, and let the streaming gains justify the rewrite on their own timeline rather than the calendar’s.

Sources cited

1. htmx 4.0.0 has been released! (htmx.org announcement) four.htmx.org
2. HTMX 4.0: Hypermedia finds a new gear (InfoWorld) www.infoworld.com
3. htmx v4.0.0 release notes (GitHub) github.com