The Framework Tax
If you started building web applications in the last decade, you probably learned that modern web development requires a JavaScript framework. React, Angular, or Vue — pick one, learn its ecosystem, configure its build tooling, and accept that your “Hello World” will ship 200KB of JavaScript before it renders a single pixel. This wasn’t anyone’s malicious plan. It was the emergent result of a thousand incremental decisions, each one reasonable in isolation, that collectively produced a stack so complex that even senior engineers joke about “JavaScript fatigue.”
But something interesting has been happening since roughly 2022. A growing number of developers have started asking a question that would have been unthinkable five years earlier: what if we just used HTML?
The answer, it turns out, has a name. It’s called HTMX, and it represents the most interesting challenge to the JavaScript industrial complex since jQuery retired.
What HTMX Actually Is
HTMX is a 14KB JavaScript library (uncompressed — 4KB gzipped) created by Carson Gross. Its premise is almost aggressively simple: extend HTML so that any element can make HTTP requests and swap the response into the DOM, without writing JavaScript. Instead of building a single-page application (SPA) with a JSON API and a client-side router, you write server-rendered HTML and use HTMX attributes to make your pages interactive.
Here’s what that looks like in practice. Instead of:
Write a React component with useState, useEffect, fetch(), JSX, and a build step that compiles it all through Webpack or Vite
…you write:
<button hx-get=”/api/likes” hx-target=”#count” hx-swap=”innerHTML”>Like</button>
That’s it. The button fires a GET request. The server returns a fragment of HTML. HTMX inserts it into the #count element. No state management library. No virtual DOM diffing. No npm install. No build step at all, unless you want one.
HTMX isn’t the first library to pursue this philosophy — Intercooler.js, its predecessor, dates back to 2013, and projects like Unpoly and Turbo (from the Rails world) share similar goals. But HTMX has captured developer attention in a way its predecessors didn’t, and the numbers back it up. As of late 2024, the HTMX GitHub repository has over 36,000 stars. It’s been adopted in production by companies including Django, Quora, and a growing list of startups that have publicly abandoned React in favor of simpler stacks.
The Problems HTMX Solves (and the Ones It Doesn’t)
HTMX’s value proposition is clearest when contrasted with the SPA architectures it challenges. The SPA model was born from a real problem: traditional multi-page applications felt slow because every interaction required a full page reload. SPAs solved this by moving UI logic to the client, communicating with the server through JSON APIs and updating the page in place.
But this architecture introduced costs that weren’t obvious at first:
- Duplicated logic: Validation, routing, and authorization often need to be implemented twice — once on the server, once on the client.
- Build complexity: What used to be “save a file and reload” became an elaborate pipeline of bundlers, transpilers, minifiers, and code-splitters.
- SEO fragility: Despite improvements in server-side rendering frameworks like Next.js, SPAs still create SEO complexity that multi-page apps don’t have.
- State synchronization: Keeping the client’s state consistent with the server’s state — the “single source of truth” problem — spawned an entire sub-industry of state management libraries.
HTMX sidesteps all of this by making the server the single source of truth. The client requests HTML. The server returns HTML. The client inserts it. State management becomes a server-side concern, where most applications already have a database and application logic.
But HTMX isn’t a panacea. Applications that need rich client-side interactivity — collaborative editing, real-time dashboards, complex animations — will still need JavaScript. The question isn’t “should everything be HTMX?” but rather “does this specific application actually need a SPA?”
Adoption Data: Who’s Actually Using This?
Quantifying framework adoption is notoriously difficult, but several data points suggest HTMX’s growth is real, not just Hacker News hype.
The 2024 State of JavaScript survey reported that 18% of respondents had used HTMX, up from 8% in 2023 — the fastest-growing library in the survey. Stack Overflow’s 2024 developer survey listed HTMX among the most “admired” web frameworks, with 72% of developers who tried it saying they wanted to continue using it.
More telling is the production adoption. The European Space Agency’s public-facing websites moved to HTMX in 2024. Django’s official tutorial was rewritten to feature HTMX as the recommended approach for dynamic functionality. Companies like Buttondown (newsletter platform), Screaming Frog (SEO tools), and a number of Y Combinator startups have migrated from React or Vue to HTMX-powered stacks.
“We deleted 40,000 lines of JavaScript and replaced it with 3,000 lines of HTMX attributes,” wrote one engineering lead in a widely-shared post-mortem. “Our Lighthouse scores went from the 60s to high 90s. Our time-to-interactive dropped by 70%. And onboarding a new developer went from two weeks to two days.”
These aren’t universal experiences — teams building Figma or Google Docs aren’t going to replace their SPAs with HTMX. But the category of applications that don’t actually need a full SPA is much larger than the industry assumed through the 2010s.
The Philosophical Shift: HATEOAS and the Web That Was
HTMX’s creator, Carson Gross, frames the library not just as a technical tool but as a philosophical argument. He’s an advocate for HATEOAS (Hypermedia as the Engine of Application State), a constraint of the REST architectural style that the industry largely abandoned in the JSON API era.
The idea is simple: a web application should work like the web itself. You request a resource. The server returns a representation that includes not just data but also the actions available to you — links, forms, buttons. You follow those links. You submit those forms. The server responds with a new representation. Your browser handles the plumbing.
In practice, this means HTMX applications tend to feel more like traditional web applications — pages that happen to update smoothly — rather than the app-in-a-page experience of SPAs. For many use cases, that’s not a downgrade. It’s a better fit.
The Bigger Picture: Complexity Budgeting
HTMX’s real contribution may not be technical at all. It’s forcing the industry to have a conversation about complexity budgets — the idea that system complexity is a cost, not a feature, and should be treated the same way you treat infrastructure spending or technical debt.
The JavaScript ecosystem didn’t become complex because developers are bad at their jobs. It became complex because the problems were genuinely hard and the tools evolved incrementally. But it’s also true that the industry defaulted to SPAs for applications that didn’t need them, because SPA frameworks became the default answer to “how do I build a web app?”
HTMX offers a different default. Not for everything. Not forever. But for more applications than we’ve been willing to admit.
The Counterargument: Why SPAs Still Dominate
It would be intellectually dishonest to portray HTMX as an unambiguous winner. Single-page applications exist for good reasons, and millions of developers build with React every day because it genuinely solves hard problems. Complex state management, offline-first experiences, real-time collaboration, push notifications, and rich client-side interactivity are all domains where the SPA architecture shines. A Google Docs, a Figma, or a Discord simply cannot be built with HTMX — those applications are closer to desktop software running in a browser than to websites.
The SPA ecosystem has also matured. React Server Components, introduced with React 18 and championed by the Next.js framework, represent a genuine attempt to reclaim some of the simplicity that the SPA model discarded — rendering components on the server by default and sending HTML to the client where possible. The irony is that React is moving toward a model that looks more like the server-rendered approach HTMX advocates, just with a much more complex implementation.
The realistic takeaway is that the web development landscape is diversifying, not polarizing. Teams that need maximum interactivity will keep building SPAs. Teams building content-heavy sites, admin panels, CRUD applications, and internal tools are increasingly discovering that they can ship faster, with less code, using the hypermedia approach. The “one framework to rule them all” era may be ending — and that’s probably healthy.
A Practical Decision Framework
If you’re evaluating whether HTMX (or a similar library) fits your next project, here’s a useful heuristic:
- Is your application primarily forms, lists, and navigation? HTMX is probably a strong fit.
- Does every user interaction need updates to shared state across the whole page? You may need a more sophisticated client-side model.
- Do you need offline support or real-time synchronization? A SPA (or a hybrid) is more appropriate.
- How big is your team, and what do they already know? HTMX has a much shallower learning curve, which matters if you’re onboarding developers who aren’t JavaScript specialists.
- What’s your performance budget? If you’re optimizing for time-to-interactive and Core Web Vitals, fewer client-side dependencies almost always win.
None of this is a referendum on React’s quality. It’s a recognition that the tool should match the job. For a surprisingly large share of web projects, the simpler tool is the better one — and HTMX is finally making that option respectable again.
