# htmx 4.0 moves its core to fetch and makes streaming HTML a first-class path htmx 4.0 replaces its XMLHttpRequest internals with `fetch()`, makes attribute inheritance explicit, changes default history behavior and ships first-party SSE, WebSocket and multipart streaming extensions. The team is deliberately keeping 2.x as npm’s `latest` until early 2027, so adoption is an opt-in migration rather than an automatic upgrade. The htmx 4.0 release changes several long-standing browser and application assumptions while keeping the hypermedia model intact. Builders get streaming HTML and modern fetch internals, but need to test inherited attributes, event names and history behavior before migrating. - Status: Active - Published: 2026-08-29T17:11:09+12:00 - Updated: 2026-08-29T17:11:09+12:00 - Categories: Web Development, JavaScript, Frameworks - Tags: fetch API, htmx, hypermedia, streaming HTML - Canonical HTML: https://beyondthe.news/dossiers/htmx-4-fetch-streaming-html-sse-websocket-history-inheritance ## What changed On August 28, 2026, the htmx project released htmx 4.0 after roughly eight months of development. The core networking layer has moved from `XMLHttpRequest` to the modern `fetch()` API, enabling a cleaner async implementation and new streaming behavior. Version 4 also changes attribute inheritance so inheritance must be explicit rather than assumed, standardizes event naming, stops using `localStorage` for history by default, and adds new `hx-download`, `hx-alpine-compat` and `hx-history-cache` features. The release includes first-party extensions for streaming HTML over Server-Sent Events, WebSockets and `multipart/mixed`, plus the new `hx-live` scripting layer and an `htmax.js` bundle. Despite the major release, the project is intentionally leaving htmx 2.x as npm's `latest` tag until early 2027 to avoid silently upgrading CDN and unpinned installations. ## Why it matters htmx is used precisely because it lets server-rendered applications add interactivity without adopting a large client framework. Version 4 modernizes that model without abandoning it, and the streaming extensions make incremental server-driven UI updates a more direct architectural option for AI outputs, long-running jobs and real-time applications. The migration also contains enough behavioral changes to deserve deliberate testing: inherited attributes and browser history can affect application behavior far from the code that triggered the request. By keeping 4.0 on npm's `next` channel, the project is explicitly treating the release as an opt-in compatibility boundary rather than forcing ecosystem-wide adoption. ## The transport layer moves from XHR to fetch htmx historically used XMLHttpRequest for broad backwards compatibility. Version 4 rewrites the core request path around `fetch()` and async JavaScript. For ordinary requests the project says behavioral differences from 2.x are relatively small, but the new foundation makes streaming responses and modern browser primitives substantially easier to support. ## Streaming HTML becomes part of the official ecosystem The 4.0 release includes `hx-sse` for `text/event-stream`, `hx-ws` for WebSockets and `hx-multipart` for `multipart/mixed` streaming responses. Instead of waiting for one complete HTML response, applications can progressively deliver server-rendered fragments. That is useful for long-running server work, live dashboards and AI generation where the server can emit meaningful UI before the whole job completes. ## Attribute inheritance is intentionally less implicit htmx 4 changes inheritance behavior so inherited attributes are explicit. This reduces hidden behavior travelling down large DOM subtrees, but applications that relied on 2.x inheritance can break even when the affected element itself was not edited. The project provides migration guidance and tooling because this is one of the more consequential compatibility changes. ## History behavior changes to avoid persistent local storage by default The default history path no longer stores htmx history snapshots in `localStorage`; version 4 prefers re-fetching content. A separate `hx-history-cache` extension can use `sessionStorage` when a client-side history cache is desired. Builders should test offline/back-navigation behavior, request load and pages whose historical state cannot be safely reconstructed from the server. ## The project is deliberately preventing accidental upgrades Although the website now documents 4.0, the htmx team says npm's `latest` tag will remain on the 2.x line until early 2027, while 4.0 stays under `next`. That protects users relying on unversioned CDN or package references but also means a normal update command may not move an application to the new major version. ## Key details - htmx 4.0.0 was released on August 28, 2026. - The core request implementation moved from XMLHttpRequest to the Fetch API. - The release includes first-party streaming extensions for SSE, WebSockets and multipart/mixed responses. - Attribute inheritance is explicit by default in htmx 4 rather than relying on 2.x-style implicit inheritance. - Default history behavior no longer uses localStorage; `hx-history-cache` provides an optional sessionStorage-based cache. - New additions include `hx-download`, `hx-alpine-compat`, `hx-live` and the `htmax.js` bundle. - htmx 2.x remains npm's `latest` version for now; 4.0 is intentionally published on the `next` track until early 2027. ## Builder takeaways - Pin the htmx version explicitly before migration testing; do not assume npm or a non-versioned CDN reference will move to 4.0 automatically. - Run the project’s upgrade tooling and search for inherited htmx attributes, because inheritance changes can create subtle regressions far from the triggering element. - Test back/forward navigation and history-sensitive screens separately; the default switch away from localStorage can change both network behavior and reconstructed UI state. - If you currently build custom streaming glue for AI or long-running server responses, evaluate the official SSE, WebSocket or multipart extensions before maintaining another client-side transport layer. - Adopt streaming only where progressive UI improves the task. A conventional complete HTML response remains simpler for short requests and easier to cache/debug. ## What to watch - When the project changes npm's `latest` tag from 2.x to the 4.x line in early 2027. - Real-world compatibility reports around explicit attribute inheritance and changed history semantics. - Whether streaming HTML extensions converge on common server implementation patterns across PHP, Rails, Django and other server-rendered stacks. - Adoption and stability of `hx-live` and the combined `htmax.js` distribution. - Whether browser and framework tooling adds stronger support for inspecting streamed htmx fragment updates. ## Uncertainties - The project describes behavioral differences from 2.x as relatively small overall, but the practical migration impact varies heavily with use of inheritance, history and extensions. - The streaming extensions are new enough that broad independent production evidence is limited. - Keeping 4.0 off npm's `latest` tag means ecosystem adoption and plugin compatibility will develop gradually rather than all at once. ## Sources - [htmx 4.0.0 has been released!](https://four.htmx.org/announcements/2026-08-28-htmx-4.0.0-is-released) — htmx · primary · 2026-08-28T00:00:00+12:00. Official major-release announcement covering fetch internals, compatibility changes, streaming extensions, new features and the deliberate npm `next` rollout.