By ByteBot
HTMX creator Carson Gross promised there would never be a version 3.0—version 2.0 was “complete and adequate,” he said. He kept that promise. The team just released version 4.0 instead. HTMX 4.0 rips out the XMLHttpRequest engine and replaces it with the modern Fetch API, enabling streaming responses that process HTML fragments as they arrive instead of buffering complete responses.
Why Skip Version 3.0?
Carson Gross had committed publicly to never releasing HTMX 3.0. Version 2.0 was declared final, and that was supposed to be it. But the team discovered something during development: the Fetch API with async/await could enable a dramatic internal redesign. Switching from XHR to Fetch unlocked streaming via ReadableStreams, simplified the codebase, and brought HTMX in line with modern web standards. The problem? These changes were breaking enough to warrant a major version bump.
The solution is both pragmatic and slightly cheeky: skip version 3.0 entirely and jump straight to 4.0. Honor the promise while acknowledging reality. As Gross emphasized: “We are going to work to ensure that htmx is extremely stable in both API & implementation.”
Fetch API Unlocks Streaming
The core technical win in HTMX 4.0 is streaming. XMLHttpRequest buffers the entire response before handing it to your application. You send a request, wait for everything to load, then swap the HTML. Fetch API with ReadableStreams processes and injects HTML fragments as they arrive. Your UI updates incrementally—the first section renders while the rest streams in.
This is progressive rendering. The front end doesn’t wait for the complete response. It acts on segments as they show up. For data-heavy dashboards, admin panels, or any server-rendered app that streams content, the improvement is tangible. Server-Sent Events return to HTMX’s core as a specialized streaming implementation, and the whole package still clocks in at 14KB minified and gzipped.
Compare that to React at 47KB. HTMX achieves streaming, progressive updates, and hypermedia-driven interactivity while shipping 3.4x less JavaScript. For teams building CRUD applications, content platforms, or internal tools, that size difference compounds with every page load.
Breaking Changes to Know
HTMX 4.0 introduces several breaking changes. Attribute inheritance switches from implicit to explicit by default. In version 2.0, child elements automatically inherited parent attributes like hx-target and hx-swap. In 4.0, you must explicitly mark them with :inherited.
Error response handling flips. HTMX 2.0 didn’t swap 400 and 500 responses by default. HTMX 4.0 does. If your server returns HTML with a 422 or 500 error code, that HTML gets swapped into the target. Your error responses must produce valid swap content now.
History navigation simplifies. Version 2.0 used DOM snapshotting for back button behavior. Version 4.0 just makes a network request for the content. Default timeout shifts from 0 to 60 seconds. Attribute names change: hx-disable becomes hx-ignore, and hx-disabled-elt becomes hx-disable.
The migration safety net is solid. The htmx-2-compat extension restores implicit inheritance, old event names, and previous error-swapping defaults during transition. More importantly, HTMX 2.0 remains supported indefinitely. New projects can start with 4.0. Existing applications can stay on 2.0 perpetually if that makes sense.
The HTMX Renaissance Continues
HTMX 4.0 lands in the middle of what developers are calling the “HTMX Renaissance.” The 2025 State of JS survey shows React still commanding 83.6% usage, but its satisfaction score hit its lowest point. HTMX holds “most admired” status among developers who’ve tried it. The framework gained 16,800 GitHub stars in 2024—more than React gained in the same period.
The download gap is still massive. React sees 96 million weekly downloads. HTMX clocks 94,000. That’s a 1,000x difference. But the trajectory matters. Developers are exhausted with 200MB node_modules directories, webpack configurations that require a PhD, and learning a new state management library every six months.
Teams migrating to HTMX report 30-50% less code compared to equivalent React or Vue applications. One developer removed more than 3,000 lines of JavaScript after switching to HTMX for a Django app. For CRUD-heavy applications, the reduction in frontend code ranges from 40-60%. Server-rendered HTML with hx-* attributes handles the interactivity.
The prediction for 2026 is that “pure” SPAs become a niche choice, reserved for applications like Figma, Notion, and Google Docs. Most of the web moves toward a hybrid model: HTMX for the data-heavy skeleton, “Islands of Interactivity” for specific widgets that need instant client-side feedback.
What This Signals
HTMX 4.0 validates what developers have been saying for years: “SPA-by-default” was wrong for most applications. The Fetch API adoption brings HTMX in line with modern web standards while proving that hypermedia can evolve with the platform. Streaming isn’t a React exclusive feature anymore. Progressive rendering works with 14KB of JavaScript if you architect around HTML instead of client-side state.
React wins for rich, desktop-like applications with heavy client-side computation, complex state management, and offline-first requirements. HTMX wins for server-rendered apps, CRUD applications, and content-heavy sites where you want minimal JavaScript and maximum maintainability. HTMX 4.0 can now stream responses and progressively render UIs, closing the gap on one of the last advantages SPAs held.
For developers building with Django, Rails, or Laravel, HTMX 4.0 is a clear upgrade path. The streaming capabilities align with server-side rendering workflows, and the framework-agnostic design means it drops into any backend stack. If you’re starting a new project in 2026 and most of your logic lives on the server, HTMX 4.0 makes a strong case. If you’re running HTMX 2.0 and it’s working, there’s no rush—the support commitment is indefinite.
