---
title: "htmx vs React"
slug: "htmx-vs-react"
category: "comparisons"
tags: ["comparisons", "htmx", "react", "frontend", "ssr", "spa"]
status: "stable"
last_updated: 2026-05-14
summary: "Pick htmx for server-driven apps where the server owns state; pick React for SPAs with rich client state and a dedicated frontend team."
related: ["[[frontend/react]]", "[[comparisons/server-vs-client-components]]", "[[comparisons/react-vs-vue]]", "[[frontend/react-state-management]]", "[[frontend/react-suspense]]", "[[frontend/forms]]", "[[backend/fastapi]]", "[[comparisons/fastapi-vs-django]]"]
---

## 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 [[frontend/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 [[frontend/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 [[comparisons/tanstack-query-vs-swr]].

## Trade-offs at a glance

| Dimension              | htmx                            | React                                |
| ---------------------- | ------------------------------- | ------------------------------------ |
| Mental model           | Server-driven, HTML over wire   | Client-driven, JS state              |
| Client size            | 14 KB                           | 50 to 200 KB plus app code           |
| Build step             | None                            | Required (Vite, Next.js, etc.)       |
| State location         | Server (database)               | Client (hooks, stores, cache)        |
| Round-trip per action  | Yes, always                     | Optional; can be optimistic          |
| SEO                    | Native; HTML out of the box     | Needs SSR or RSC                     |
| Accessibility default  | Strong (semantic HTML)          | Strong with discipline               |
| Hiring pool            | Small; backend-fluent           | Largest in 2026                      |
| Offline                | Not supported                   | Strong with service workers          |
| Animation              | CSS transitions only            | Framer Motion, GSAP, native          |
| Ecosystem              | Small, focused                  | Vast; the de facto standard          |
| LLM agent output       | Tiny surface; agents do well    | Mature 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 [[frontend/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 [[comparisons/fastapi-vs-django]] on the server.
- SaaS dashboard with charts, filters, and saved views: React. See [[frontend/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.

## Related

- [[frontend/react]]
- [[comparisons/server-vs-client-components]]
- [[comparisons/react-vs-vue]]
- [[frontend/react-state-management]]
- [[comparisons/fastapi-vs-django]]
- [[frontend/astro-islands]]