htmx 4.0 Rewrites Its Networking Core Around fetch()

htmx replaces its transport layer with fetch()

The htmx project shipped version 4.0.0 on August 28, 2026, after roughly eight months of work rebuilding the library's core networking engine around the browser's fetch() application programming interface (API) in place of the older XMLHttpRequest (XHR) API. The community has taken to calling the effort "the Fetchening." The change is largely invisible in day-to-day markup, but it unlocks something XHR could not do well: htmx can now process and inject HTML fragments into the page as they stream in, instead of waiting for the entire server response to arrive first.

An accidental major version

htmx's creator, Carson Gross, had previously said there would never be a backwards-incompatible htmx 3.0. That promise held, technically, only because the fetch() rewrite ended up forcing enough breaking changes that the team skipped straight past 3.0 to 4.0. Asked about the jump, Gross offered a one-word explanation to InfoWorld: "Oops." The team maintains that for most everyday usage the behavioral differences between 2.x and 4.x are relatively small, even though the internal rewrite was substantial.

What actually breaks

Three changes in htmx 4.0 require real migration work:

• Attribute inheritance is no longer implicit. Attributes such as hx-confirm or hx-target used to cascade down the DOM automatically. In 4.0, that inheritance must be explicitly declared with an :inherited suffix, for example hx-confirm:inherited="Are you sure?".
• Event names follow a new pattern. Events now use a htmx:phase:action structure, so htmx:beforeRequest becomes htmx:before:request and htmx:afterSwap becomes htmx:after:swap. XHR-specific events, including the validation events tied to the old transport layer, were removed outright since there is no XHR object left to fire them.
• localStorage-based history caching is gone. Earlier versions cached page state in the browser's localStorage to speed up back-button navigation. That cache has been removed by default, so back navigation now re-fetches from the server, a change made to avoid conflicts with third-party scripts that mutate the DOM after the original page load. Anyone who wants the old behavior back can restore it with a new hx-history-cache extension built on sessionStorage instead.

What's new

Alongside the breaking changes, 4.0 folds in features that previously required separate extensions. Morph-style swaps, which update the DOM by diffing rather than replacing whole elements, now ship built in using an improved Idiomorph-based algorithm. A new <hx-partial> tag gives out-of-band, multi-target DOM updates a clearer syntax than the workarounds 2.x developers relied on. The release also bundles several new official extensions, including hx-preload, hx-download, hx-alpine-compat for compatibility with the Alpine.js framework, and a new in-house scripting extension called hx-live.

Why streaming was worth a major version

The XHR API buffers a full response before handing it to application code, which is fine for small JSON payloads but wasteful for large HTML fragments, particularly ones a server could start sending before it has finished generating the whole page. Rebuilding the transport layer around fetch() lets htmx read a response as it arrives and start swapping content into the DOM before the connection closes. For pages that render long lists, search results, or large partial-page updates, that changes perceived load time even when total transfer time is unchanged, because the user sees content appear progressively instead of all at once at the end.

Migration is opt-in, not automatic

The htmx team built tooling to ease the transition: a command-line checker that flags places in existing code needing the new :inherited suffix or renamed event listeners, plus a set of files meant to let AI coding assistants automate parts of the 2.x-to-4.x migration. Critically, the team also changed how the release is distributed to avoid breaking anyone by surprise. htmx 2.x stays published under npm's "latest" tag indefinitely, so existing unpinned installs will not silently pull in the breaking release. Version 4.0 is published under npm's "next" tag until early 2027, meaning developers have to opt in deliberately to get it.

What it means for developers

If you maintain a project on htmx 2.x, nothing changes automatically: you are not going to wake up on an unpinned build and find your event listeners broken. When you do plan the upgrade, budget time to audit any code relying on implicit attribute inheritance or the removed XHR-specific events, since those are the two changes most likely to break existing markup silently rather than loudly. The streaming support that motivated the whole rewrite is the real payoff, particularly for pages rendering large fragments, but it is worth adopting on your own schedule rather than rushing, given the team itself has structured the release to be entirely optional for close to half a year.