htmx vs React 2026: 4 Questions, 60 Seconds, One Answer

2026-04-23 · Nico Brandt

You’ve read five htmx vs React articles this month. Each one was 5,000 words. Each one ended with “it depends.”

You already know what htmx is. You know what React is. You don’t need another architecture diagram or philosophy lecture. You need to make a decision — preferably before Friday’s planning meeting — and nobody will give you a straight answer.

That’s because they’re giving you information when you need a diagnostic. Four questions. Sixty seconds. Let’s go.

The 4-Question Decision Test

Run these with your team. Answer honestly — not aspirationally.

Question 1: Does your UI need client-side state that changes faster than a server round-trip?

Drag-and-drop reordering. Real-time collaboration cursors. Optimistic UI that updates before the server confirms. These need state to change in under 16ms — a server round-trip can’t deliver that. If your state can wait 50–200ms for a server response, htmx handles it cleanly. If it can’t — if the lag between action and feedback breaks the experience — you’re in React territory.

Question 2: Do you need offline support?

htmx is server-dependent by design. No server, no UI updates. If your users need to keep working on a plane or in a dead zone, that’s React (or a PWA layer you’ll regret building on top of htmx).

Question 3: Is your team backend-strong or frontend-specialized?

This is the question most articles skip, and it’s often the deciding factor. A backend-strong team ships htmx features immediately — it’s HTML attributes on server-rendered templates. They don’t need to learn JSX, hooks, or a build pipeline. A frontend-specialized team already thinks in React’s component model. Forcing them into server-rendered partials slows them down.

Question 4: Is your interaction model CRUD or rich editing?

Forms, tables, filters, toggles, search — that’s CRUD. htmx was built for this and it shows. One team reported that a “Resend OTP” feature took three days in React and three hours in htmx. That’s the CRUD advantage in practice — not marginal, but order-of-magnitude. Rich text editors, canvas manipulation, complex drag-and-drop with nested containers — that’s React’s genuine territory. The line is clearer than the discourse suggests.

Score it: Three or more “no” answers → htmx ships faster. Two or more “yes” → React. Split down the middle → keep reading for the escape hatch.

That’s the framework. But frameworks are abstract until you map them to the project sitting in your backlog.

5 Project Types, 5 Verdicts

Admin panel / back-office → htmx. CRUD-heavy, internal users, backend team owns it. One team rebuilt their React admin dashboard and went from 3,200 lines to 890 — a 72% reduction — with load times dropping from 2.4 seconds to 180ms. That’s not a cherry-picked outlier. Teams consistently report 40–60% frontend code reduction when migrating CRUD apps to htmx. Admin panels are htmx’s home court.

SaaS product dashboard → depends on Q4. If your dashboard displays analytics and manages settings, htmx handles it. If it’s a Kanban board with cross-container drag-and-drop, React. The interaction model question is the decider, not the “SaaS” label.

E-commerce storefront → htmx. Catalog pages, product listings, checkout flows — all server-rendered, SEO-native, fast first paint. Server rendering means your product pages are indexable without JavaScript, and your load times benefit from smaller bundles. You only need React here if you’re building AR try-on features or complex product configurators. Most stores aren’t.

Content site → htmx (or neither). If you need a JavaScript framework for a content site, you probably don’t need a JavaScript framework at all. Static HTML with a sprinkle of htmx for interactive elements like search or filtering is plenty. Consider this: a Next.js hello world ships roughly 184KB of JavaScript. htmx is 14KB gzipped. For a content site, most of that JavaScript is dead weight that actively hurts your performance.

Collaborative tool → React. Documents, whiteboards, design tools — real-time multi-user state, offline support, sub-frame updates. htmx’s server round-trip model doesn’t hold up when two people are typing in the same paragraph. This is React’s genuine stronghold, and pretending otherwise is tribalism.

These verdicts assume the landscape as of early 2026. But the landscape shifted this month — and it pushes the line further toward htmx than most developers realize.

What Changed in 2026

Three developments reshaped the htmx vs React comparison this year.

htmx 4.0 dropped in April. The headline: XMLHttpRequest is gone, replaced by the fetch() API. That sounds like an implementation detail. It’s not. Fetch unlocks ReadableStream, which means native streaming support — partial updates flowing from server to browser without polling. Idiomorph DOM merging replaces blunt innerHTML swaps with intelligent diffing. The :inherited modifier gives you explicit control over attribute inheritance. htmx is no longer “jQuery with extra steps.” It’s a mature hypermedia client.

AI agents changed the calculus. This is the 2026-specific insight most articles miss. As AI writes more frontend code, htmx’s declarative HTML attributes are easier to generate correctly than React hook chains with useEffect dependency arrays. An AI agent can produce a working hx-get partial in one shot. Getting it to produce a correct useEffect cleanup with the right dependency array? That takes iteration — and the bugs it introduces are subtle. If your team is leaning into agentic coding workflows, htmx’s simplicity is a concrete advantage — not a philosophical one.

Edge computing nearly killed the latency argument. “But server round-trips are slow” was a valid concern in 2020. In 2026, edge functions you can deploy today put your server 20ms away, not 200ms. htmx’s server-driven UI feels instant when the server is at the edge. The performance gap between client-side rendering and server-driven hypermedia has narrowed to the point where most users can’t tell the difference.

The counterweight nobody wants to mention: React still has roughly 1,000x htmx’s npm download volume — 96 million weekly downloads versus 94 thousand. The job market reflects this. Choosing htmx means hiring backend devs who learn it in a day (easy) rather than finding “htmx developers” (rare). That’s workable for most teams, but if you’re scaling hiring fast, it’s a factor.

So htmx covers more ground than before. But what about the projects that genuinely need pieces of both?

When You Need Both (and Where htmx Hits a Wall)

The Islands pattern solves this cleanly. htmx handles the 90% of your app that’s server-rendered CRUD. React components mount into specific DOM nodes for the 10% that needs rich interactivity — a text editor here, a drag-and-drop board there. htmx doesn’t fight React for DOM ownership if you scope correctly. In practice, this means your server renders the page layout, navigation, forms, and data tables. React only loads for the components that genuinely need client-side state — and your bundle stays small because React isn’t rendering the whole page.

React Server Components offer a middle path too, but let’s be honest: RSC solves React’s bundle size problem, not htmx’s simplicity advantage. For the same CRUD use case, RSC is still more complex to set up, reason about, and debug than htmx. It’s React’s answer to htmx’s argument, not a replacement for htmx itself.

Where htmx genuinely fails — not theoretically, but in production:

A useful heuristic: if you can’t prototype the interaction in htmx in 15 minutes, it probably needs a JavaScript framework. Don’t force htmx into React’s territory — you’ll fight the architecture the entire way, and your team will blame htmx for a problem you created by misapplying it.

The Bottom Line

You came here after reading articles that told you “it depends.” It does depend — but now you know the four specific things it depends on.

The honest synthesis: htmx wins for more projects than most React developers expect. React wins for fewer projects than the React ecosystem wants to admit. The four questions cut through the tribalism in both directions.

Run the test with your team. If the answer is clear, ship. If it’s split, start with htmx for the server-rendered core and add React islands where the interaction model demands it. That’s not a compromise — it’s the architecture that matches how most applications actually work.

Now close the tab on those other five articles. You won’t need them.