Overview

Pick htmx when the server owns the data, the page is mostly HTML, and the interactivity is “swap a region on a click or a form submit.” Pick React when the product has real client state: drag-and-drop boards, multi-step wizards with cross-field validation, offline-first features, or a UI that animates and re-orders without a server round trip. The 2026 split is concrete: htmx for content sites, admin panels, internal tools, and CRUD apps; React for product surfaces where the SPA mental model is the spec. See react for the React rule set.

When htmx wins

htmx is the right pick when the page is HTML, the server is fast, and the team is small.

  • Complexity floor: a 100-line backend plus 50 lines of htmx attributes replaces a 5k-line React app for most CRUD. The savings are real, not rhetorical.
  • No build step on the client: htmx is a 14 KB script tag. No bundler, no transpile, no source maps, no node_modules on the frontend.
  • Server owns state: the database is the source of truth; you cannot have a stale Redux store because there is no store.
  • SEO and accessibility: every endpoint returns HTML. Crawlers see real content; screen readers do too without ARIA gymnastics. See accessibility.
  • Backend stack independence: htmx pairs with Django, FastAPI, Hono, Rails, or any framework that returns HTML fragments.
  • Cheap deploy: server-rendered HTML cached at the edge serves 1M users on $20 of infrastructure.

When React wins

React is the right pick when the product is SPA-shaped and the client state has a life of its own.

  • Rich interactivity: drag-and-drop, virtualized lists, real-time collaboration, kanban boards, video editors. htmx round-trips for every state change; that is too slow.
  • Offline-first or PWA: React plus IndexedDB or a CRDT library survives a flaky network. htmx assumes the server.
  • Component reuse across web, native, and TV: React Native and React for web share components. htmx is web-only.
  • Ecosystem depth: shadcn, Tailwind plugins, charting libraries, animation libraries, dnd-kit. The component catalog is the moat.
  • Hiring pool: React engineers are the largest frontend pool in 2026. htmx fluency is rare and asks for a backend-first hire.
  • Optimistic UI: React with TanStack Query or React Query updates the screen before the server confirms. See tanstack-query-vs-swr.

Trade-offs at a glance

DimensionhtmxReact
Mental modelServer-driven, HTML over wireClient-driven, JS state
Client size14 KB50 to 200 KB plus app code
Build stepNoneRequired (Vite, Next.js, etc.)
State locationServer (database)Client (hooks, stores, cache)
Round-trip per actionYes, alwaysOptional; can be optimistic
SEONative; HTML out of the boxNeeds SSR or RSC
Accessibility defaultStrong (semantic HTML)Strong with discipline
Hiring poolSmall; backend-fluentLargest in 2026
OfflineNot supportedStrong with service workers
AnimationCSS transitions onlyFramer Motion, GSAP, native
EcosystemSmall, focusedVast; the de facto standard
LLM agent outputTiny surface; agents do wellMature patterns; agents do well

Migration cost

React-to-htmx is a rewrite. htmx-to-React is also a rewrite. The interesting move is partial: htmx for the shell, React islands for the interactive bits.

  • React app that became a CRUD app: a 50k-LoC React frontend often shrinks to a 5k-LoC htmx-plus-server app. Plan four to ten engineer-weeks; bigger savings come from deleting the API layer entirely.
  • htmx app that needs one rich surface: keep htmx for the rest of the site, mount a React island on the page that needs it. Astro’s island model formalizes this pattern. See astro-islands.
  • Mixed teams: backend engineers ship htmx in hours; frontend engineers ship React in days. The team shape often picks the tool.

Recommendation

  • Internal tool, admin panel, content site, CRUD app: htmx with fastapi-vs-django on the server.
  • SaaS dashboard with charts, filters, and saved views: React. See react.
  • Product with drag-and-drop, real-time collab, or offline: React with TanStack Query.
  • Marketing site with a few forms: htmx; build step is overhead you will never recoup.
  • Multi-page app where each page does one thing: htmx.
  • One-page app where the page does many things: React.