For the better part of a decade, the default answer to almost every web project was the same: spin up a single-page application framework, ship a fat JavaScript bundle, and hope your users have the patience (and bandwidth) to wait for it all to hydrate. That era is closing. The numbers are hard to ignore — 23% of developers now use HTMX, a 350% increase in just two years, and HTMX 4.0 is entering beta this summer with features that make the case for hypermedia-driven development stronger than ever.
TL;DR
- HTMX adoption has surged 350% in two years, with 23% of developers now using it and 47,000+ GitHub stars
- HTMX 4.0 (beta, Summer 2026) replaces XMLHttpRequest with the Fetch API, enabling streaming HTML fragments in a 14KB script
- Drupal 12.x integrated HTMX into core, replacing legacy AJAX widgets — a signal that established platforms are betting on hypermedia
- Teams report 40–60% reductions in frontend code and up to 60× less JavaScript shipped compared to React-based implementations
- Hypermedia is not a replacement for every SPA — but for content sites, CRUD apps, dashboards, and internal tools, it is often the better architectural choice
What Changed — and Why Now
The shift did not happen overnight. Several forces converged to make hypermedia-driven development not just viable but genuinely attractive for production workloads.
Bundle fatigue is real. Google’s aggressive Core Web Vitals enforcement — particularly mobile-first indexing — now penalises sites that ship bloated JavaScript. A 300KB bundle for a dashboard that mostly displays data is no longer just inelegant; it is a measurable SEO and performance liability. Teams are asking a question they should have asked years ago: does this page actually need a client-side framework?
Server-side power has matured. Edge runtimes, high-performance application servers, and streaming response capabilities mean that rendering HTML on the server and sending fragments over the wire is fast — often faster than the hydration dance that SPAs require. The server is no longer the bottleneck it was in 2015.
React acknowledged the pattern. React Server Components — React’s newest architecture — is functionally very similar to what HTMX has been doing for years: running logic on the server and streaming HTML to the client. When the dominant framework in the ecosystem validates the approach, it is a strong signal that hypermedia-driven thinking has won the architectural argument, even if the implementation details differ.
HTMX 4.0: The Features That Matter
The upcoming HTMX 4.0 release is significant, not because it introduces a new paradigm — HTMX has always been about extending HTML — but because it removes the last remaining friction points.
Fetch API replaces XMLHttpRequest. This is the headline change. By adopting ReadableStream via the Fetch API, HTMX 4.0 can process and inject HTML fragments as they arrive from the server. Streaming UI — the feature that frameworks like Next.js tout as a major selling point — now comes in a 14KB script with zero build step.
Idiomorph in core. Intelligent DOM morphing (inspired by Hotwired’s Morphdom) is now included directly in the HTMX core rather than sitting in an extension. When the server sends back HTML, Idiomorph compares the existing DOM and only updates what has changed. The result is smoother transitions without the developer needing to think about diffing algorithms or virtual DOMs.
Head merging support. The new head-support extension allows more sophisticated <head> tag merging during page transitions, enabling proper management of stylesheets, meta tags, and scripts across navigation — a practical concern that previously pushed teams towards full SPA frameworks.
Where Hypermedia Wins — and Where It Does Not
Intellectual honesty matters here. HTMX is not a universal replacement for React, Vue, or Svelte. But for a surprisingly large category of web applications, it is the better architectural choice.
Strong fit
- Content-heavy sites — blogs, documentation portals, marketing sites where SEO and performance are paramount
- CRUD applications — admin panels, data management tools, internal business applications
- Dashboards — reporting interfaces that primarily display server-rendered data with occasional interactivity
- Forms and workflows — multi-step forms, approval flows, and process-driven interfaces
- Progressive enhancement — adding interactivity to server-rendered pages without a full framework rewrite
Weaker fit
- Highly interactive real-time applications — collaborative editors, complex drag-and-drop interfaces, or applications with deeply nested, interdependent client-side state
- Offline-first applications — PWAs that need to function without a server connection
- Rich media applications — video editors, design tools, or games where the client does most of the heavy lifting
The honest assessment? A significant percentage of web applications built with heavy SPA frameworks would have been better served by a hypermedia-driven approach. The team at REPTILEHAUS has seen this first-hand — projects where stripping out a client framework and replacing it with server-rendered HTML plus HTMX cut frontend code by half and improved Time to Interactive by seconds, not milliseconds.
The Drupal Signal
When Drupal — one of the largest CMS communities in the world — integrated HTMX directly into its 12.x core during 2025, it was not a niche experiment. It was a platform that serves millions of sites replacing legacy AJAX widgets with hypermedia-driven interactions. This kind of institutional adoption signals that HTMX has moved past the early-adopter phase and into mainstream infrastructure.
Django, Laravel, Spring Boot, Rails, and Phoenix all have mature HTMX integration patterns now. The library is genuinely backend-agnostic — it does not care what generates the HTML, only that HTML arrives.
What This Means for Your Stack
If you are planning a new project or re-evaluating an existing one, the question to ask is not “should we use HTMX?” but rather “does this project genuinely need a client-side framework?”
Start with the interaction model. Map out what your users actually do. If most interactions are request-response — click a button, see updated data, submit a form, navigate to a page — then a hypermedia approach will likely be simpler, faster, and cheaper to maintain.
Consider the team. HTMX has a dramatically lower learning curve than React or Vue. Backend developers who already know HTML can be productive immediately. For smaller teams or teams where frontend specialisation is thin, this is a genuine advantage.
Think about long-term maintenance. An HTMX application is, fundamentally, a server application that returns HTML. There is no separate frontend build pipeline, no Node.js toolchain to maintain, no hydration bugs to debug. The operational simplicity compounds over time.
Do not force it. If your application genuinely needs rich client-side interactivity — real-time collaboration, complex state management, offline capability — then a client-side framework is still the right call. The goal is not ideological purity; it is choosing the right tool for the problem.
The Broader Architectural Shift
HTMX is part of a broader correction in web development. Server Components in React, Hotwire in Rails, LiveView in Phoenix, Blazor Server in .NET — the industry is converging on a pattern where the server does more and the client does less. The pendulum that swung hard towards thick clients is swinging back.
This does not mean JavaScript frameworks are dying. It means the default assumption — that every project needs one — is dying. And that is a healthier place for the industry to be.
At REPTILEHAUS, we have been building with this philosophy for years: choose the architecture that fits the problem, not the one that is trending on Twitter. For some projects, that means React or Next.js. For others, it means server-rendered HTML with a sprinkle of HTMX. The rise of hypermedia-driven development simply gives teams more confidence that the simpler approach is not a compromise — it is often the better engineering decision.
If you are wrestling with frontend complexity, shipping more JavaScript than your application needs, or simply wondering whether there is a simpler way to build what you are building — get in touch. Our team specialises in helping businesses choose and implement the right architecture for their needs.
📷 Photo by Christopher Gower on Unsplash
