HTMX vs React 2026 — you probably don't need a SPA

If you are building a server-rendered CRUD app with Django, Rails, Go, or any backend that already renders HTML, HTMX will cut your JavaScript footprint by 80–90% and your bundle size by similar margins. Use React when your UI has complex client state, real-time collaboration, drag-and-drop, or you need the depth of the npm ecosystem.

Who this is for

Python, Go, and Ruby developers who want to add interactivity without adopting a full SPA framework. React developers wondering whether their stack is more complex than the problem requires. If you are building a mobile app, an offline-first PWA, or a real-time collaborative editor, skip to where HTMX fails now.

What we measured

HTMX 2.0.10 against React 19 (released December 2024). Bundle sizes from Bundlephobia. Ecosystem data from npm trends (week of 2026-05-10), GitHub Rising Stars 2024, and State of JS 2024. Performance figures from published migration case studies (Contexte, Kutt, OpenUnited) with methodology cited per finding.

HTMX vs React: findings

1. Bundle size and time-to-interactive

HTMX 2.0.10 ships at 17.6 KB gzipped, with zero dependencies and no build step. React 19 + ReactDOM is roughly 45 KB gzipped before you add a router, state library, or component kit.

The gap compounds at the application level. When Kutt, an open-source URL shortener, migrated from Next.js to HTMX, total page size dropped from 800 KB to 100 KB — an 87.5% reduction. Contexte, a French news platform, saw first paint drop from 2–6 seconds to 1–2 seconds (a 50–60% improvement in time-to-interactive) after replacing React with HTMX.

HTMX achieves this because it has no virtual DOM, no reconciliation pass, and no client-side routing. The server sends HTML fragments. The browser patches the DOM directly. There is nothing to parse, tree-shake, or hydrate.

2. The mental model: hypermedia vs. JSON API

HTMX is not a component library. It is a different architecture. Carson Gross, HTMX’s author, frames it as the synthesis of an old thesis-antithesis: MPA (multi-page app) → SPA → HDA (Hypermedia-Driven Application).

In an HDA, the server is authoritative. A button click sends a request; the server returns an HTML fragment; HTMX swaps it into the page. You write hx-get="/search?q=foo" and hx-target="#results". The server renders a <ul> and sends it back. No JSON, no fetch wrapper, no state update, no re-render cycle.

React 19 added Server Components (December 5, 2024), which moves rendering server-side. But Server Components still serialize a JSON-like tree that the client runtime deserializes — it is not raw HTML. The client bundle is smaller, but the mental model is still component-driven, and the tooling complexity is React-level.

The HDA model clicks immediately for developers who think in server templates. It is a context switch if you have spent years thinking in components.

For a full production assessment of the React 19 upgrade itself, see React 19: upgrade or wait?.

3. Ecosystem reach

The download gap is substantial. React pulls 545 million npm downloads per month. HTMX pulls 677,000 — a 807× gap. State of JS 2024 shows React used at work by 8,548 respondents (rank 1); HTMX by 316 (rank 9).

GitHub Rising Stars 2024 tells a different story: HTMX added 16,800 stars (rank 1 in front-end), React added 14,200 (rank 2). HTMX is growing fast from a small base. React is growing slower from a very large one.

What the numbers mean in practice: React has a component ecosystem no other library matches. ShadCN, MUI, Radix, Tanstack Query, Zustand, React Hook Form — all solved, all maintained, all documented. HTMX has no equivalent. You pick up Alpine.js for client-side state, a CSS framework for components, and write more server-side logic yourself. That trade-off is acceptable (often desirable) for teams with strong backend developers. For frontend-heavy teams, the ecosystem gap is real friction.

4. Developer experience with modern backends in 2026

If your backend already renders HTML (Django templates, Rails ERB, Go html/template, Jinja2), adding HTMX is a few script tags and some hx-* attributes. No build pipeline, no node_modules, no TypeScript config.

Contexte reported a 67% reduction in lines of code, a 96% reduction in JavaScript dependencies, and an 88% reduction in build time after migrating from React. OpenUnited saw a 61% reduction in LOC and 72% fewer files. The Paris 2024 Olympics team shipped a Django + HTMX critical network automation tool in 8 weeks — against an 18-month estimate for the full React alternative.

These are migration wins from teams that had already invested in React. Greenfield HTMX projects skip the migration cost entirely. If you are choosing between Django and FastAPI for that backend, our Django vs FastAPI comparison covers the 2026 trade-offs.

For teams using AI coding tools like Cursor in 2026, there is one nuance worth noting: AI pair programmers are trained heavily on React and TypeScript. HTMX-specific patterns (swap strategies, hx-boost, server-sent events with hx-sse) are underrepresented in training data. You will get better out-of-the-box AI completions on React code. That gap is narrowing, but it is real today.

5. Where HTMX fails

Gumroad, the e-commerce platform, evaluated HTMX and explicitly rejected it. Their five reasons are the clearest articulation of HTMX’s limits:

Dynamic validation — form validation that requires instant, complex client-side feedback (field interdependencies, async checks) is awkward without JavaScript.
Default UX is boring — HTMX’s hypermedia model pushed Gumroad’s app toward a basic Rails/CRUD interface, leading to “a really poor (or at least, boring and generic) user experience by default.” Their target product needed something richer than that.
AI tooling gap — as noted above, AI pair programmers are less fluent in HTMX patterns.
Ecosystem gaps — no component library at the maturity of ShadCN or MUI.
Real-time collaboration — multi-user live editing (think Figma, Notion, Linear) requires WebSocket-synced client state. HTMX can use WebSockets via hx-ws, but the architecture fights the problem.

Beyond Gumroad’s list: HTMX struggles on unreliable networks. The HDA model assumes a fast round-trip to the server for every interaction. In kiosk deployments or spotty mobile connections, that latency is user-visible. Gross himself concedes that latency is server-gated, and that the “80 of 80/20” case for JavaScript is animations — where HTMX intentionally stays out of the way.

HTMX has no mobile story, no offline-first path, and no component library with the maturity of ShadCN or MUI. Those are not bugs; they are intentional scope limits. Know them before you commit.

Verdict

Pick HTMX if…	Pick React if…
Your backend already renders HTML (Django, Rails, Go)	Your UI has complex client state (multi-step wizards, real-time collab)
Bundle size and TTI matter and you can’t afford hydration	You need drag-and-drop, canvas, or animation-heavy UI
Your team is backend-strong and wants to stay full-stack without a JS build pipeline	Your team is React-fluent and the ecosystem depth matters
The app is CRUD-heavy with moderate interactivity (search, filters, pagination, modals)	You are building a mobile app or need offline-first
You want to ship fast without a long tooling setup	Your AI coding tooling does better work in TypeScript/React (likely in 2026)

Neither is objectively better. The Contexte and Kutt migrations demonstrate real wins when HTMX fits. The Gumroad rejection demonstrates equally real limits when it doesn’t. Match the tool to the problem, not to hype.

Caveats

We did not run our own benchmarks on production hardware — the performance figures are from published case studies. Migration wins (Contexte, OpenUnited) reflect teams that had pre-existing React complexity; greenfield HTMX projects will have different cost curves. The AI tooling gap is based on observed completion quality in early 2026 and will change as models are retrained.

The Cursor link above is an affiliate link.