htmx in 2026: The Single-File Hypermedia Comeback

For years the assumption was that a serious web app needs a JavaScript framework. React owns the client, you manage state, you ship a build step. htmx keeps asking a more boring question: what if the server, which already renders HTML, just swapped in the pieces that changed?

It is a small library from bigskysoftware that extends HTML with attributes like hx-post and hx-swap. Any element can issue an HTTP request; any element can be replaced by the response. No routing layer, no client-side state store, no build toolchain. Just HTML in, HTML out.

The numbers are hard to argue with

The project README calls core htmx about 14 KB minified and gzipped, dependency-free and extendable. By 2026 a docs PR updated that to roughly 16 KB based on a jsDelivr measurement, but either figure undersells the point: you load one file and it is done. The same README claims code bases shrink 67% versus an equivalent React app. The best-documented example is a much-referenced 2022 DjangoCon talk: French media company Contexte replaced a two-year-old React UI with Django templates and htmx in a couple of months, and saw its front-end code and complexity shrink dramatically.

Adoption has followed. htmx has grown past 46,000 GitHub stars, and the 2024 surveys put the goodwill in numbers: it was the number one JavaScript Rising Star in the frontend category and finished second on the Stack Overflow Developer Survey list of most admired web frameworks, admired by more than 72% of respondents who knew it. Tiny usage share next to React, outsized goodwill. That gap is the story: developers keep finding that the simple tool does the job without the SPA tax.

What 2.0 did for it

htmx 2.0 shipped in June 2024. It tightened defaults, dropped Internet Explorer, and moved hx-sse and hx-ws out of core into separately versioned extensions. That split is deliberate. It is how a dependency-free single file stays a dependency-free single file while WebSockets and Server Sent Events keep improving. Live tables, chat streams, and server-pushed notifications still work, just through the sse and ws extensions instead of the core build.

When htmx is the right call

Start here when the server already owns the state: content sites, CRUD-heavy admin panels, dashboards, any hypermedia-shaped app. If you build with Django, Rails, Laravel, or plain server rendering, htmx buys interactivity with one script tag and none of the client-side state machinery. The Contexte case is the honest template. It is a content-focused application, and it is exactly what the tool is for.

When it is not

Keep the honest part. htmx is the wrong fit when you need a genuinely complex client: offline-first editing, optimistic concurrency across many entities, or a canvas-heavy interface where the browser must track heavy local state. For those, the community's own framing stands: use htmx for the server-driven surface and Alpine.js for light islands of UI state, and reach for React or Svelte when the client state is the product. htmx is not a replacement for classic SPA frameworks, and it does not need to be. It is the single-file answer for the majority of applications that should never have become SPAs in the first place.