HTMX vs React 2026: Which Should You Actually Use?

HTMX is 14KB. React + ReactDOM is ~47KB — before you add a router, state management, and a build system.

React has 96 million weekly downloads. HTMX has 94,000. That's a 1,000x gap. But HTMX gained 16,800 GitHub stars in 2024 — more than React gained in the same period. Developers aren't just curious about HTMX. They're using it.

These aren't competing tools in the traditional sense. They represent fundamentally different philosophies about how the web should work. We compared both using real data from PkgPulse. Here's what the numbers say — and when each approach makes sense.

HTMX vs React: Key Stats Compared

Metric	React	HTMX
Weekly Downloads	96M	94K
GitHub Stars	234K+	42K+
Stars Gained (2024)	~12K	~16.8K
Bundle Size (min+gzip)	~47KB (react + react-dom)	14KB
npm Ecosystem Packages	6,000+	~35
First Stable Release	2013	2020 (1.0)
Current Version	19.x	2.x
Language Required	JavaScript/TypeScript	Any server language
Build Step Required	Yes (typically)	No
License	MIT	BSD 2-Clause

See the full live comparison — download trends and health scores — at pkgpulse.com/compare/htmx-vs-react

The headline stat: HTMX beat React in GitHub stars gained in 2024 — in the "Front-end Frameworks" category of JavaScript Rising Stars. That's not a download comparison; it's a momentum signal. Developers are actively exploring alternatives to the SPA paradigm.

The Architectural Divide

This comparison isn't "which library is better." It's "which model fits your application."

React: Client-Side Application Model

React builds applications in the browser. The server sends JavaScript. The browser executes it, builds a virtual DOM, renders the UI, and handles all user interactions client-side. Data flows through API calls (REST or GraphQL).

Server → JSON API → JavaScript → Virtual DOM → HTML

The browser does the heavy lifting. The server is a data API.

HTMX: Server-Rendered HTML Model

HTMX extends HTML with attributes that make any element capable of issuing HTTP requests and swapping content — without writing JavaScript. The server renders HTML. HTMX swaps HTML fragments into the page.

Server → HTML fragments → DOM swap (no JavaScript needed)

The server does the heavy lifting. The browser displays HTML.

<!-- HTMX: A button that loads content without JavaScript -->
<button hx-get="/api/users" hx-target="#user-list" hx-swap="innerHTML">
  Load Users
</button>
<div id="user-list"></div>

That's it. No JavaScript, no build step, no state management. Click the button, HTMX fetches /api/users, the server returns an HTML fragment, HTMX swaps it into #user-list.

HTMX vs React Bundle Size: 14KB vs 200KB+

The numbers here are stark.

Metric	React (typical app)	HTMX
Framework size	~47KB (react + react-dom)	14KB
Typical app bundle	200-500KB+	14KB (just HTMX)
Build step	Required (Vite, webpack, etc.)	None
Time to Interactive	1-3 seconds (hydration)	Near-instant

A typical React app ships 200KB+ of JavaScript after adding a router, state management, and UI components. That JavaScript needs to be downloaded, parsed, compiled, and executed before the page becomes interactive.

An HTMX app ships 14KB of HTMX. The rest is server-rendered HTML — which browsers are extremely fast at parsing and displaying. There's no hydration step, no virtual DOM diffing, no JavaScript initialization.

On mobile devices and slow connections, this difference is dramatic. A budget Android phone on a 3G connection will render an HTMX page in under a second. The same React app might take 5-10 seconds to become interactive.

The caveat: HTMX makes more server round-trips. Each interaction hits the server. React can handle many interactions purely client-side after the initial load. For highly interactive UIs with complex client-side state, React's upfront JavaScript cost amortizes over user interaction time.

For a deeper dive into why JavaScript payload matters, see our guide on why bundle size matters more than framework choice and how to reduce JavaScript bundle size.

HTMX vs React Performance: Different Trade-offs

React Strengths

• Complex UI interactions — drag-and-drop, real-time collaboration, rich text editing
• Offline capability — service workers + client-side state enable offline-first apps
• Reduced server load — rendering happens in the browser, not on your servers
• Optimistic updates — update the UI before the server confirms

HTMX Strengths

• Initial page load — server-rendered HTML is faster than JavaScript hydration
• Consistent performance — no client-side JavaScript means no performance variation across devices
• Server-side simplicity — your server renders HTML, which is what servers have always done
• Lower client CPU — no virtual DOM diffing, no garbage collection pauses from JavaScript

A benchmark comparison tells the story: for a typical CRUD application, HTMX delivers content to the user 40-60% faster on first load. For a complex interactive dashboard with real-time updates, React handles the interactions more smoothly after the initial load.

Developer Experience

React: JavaScript Everywhere

React requires a JavaScript/TypeScript development environment:

npm create vite@latest my-app -- --template react-ts
cd my-app && npm install
npm install react-router-dom @tanstack/react-query zustand
# Configure routing, state management, data fetching...

Before writing your first feature, you've made decisions about routing, state management, data fetching, styling, and build tooling. The ecosystem is powerful but the decision fatigue is real.

HTMX: Use Your Backend Language

HTMX works with any server that returns HTML. Python, Go, Ruby, PHP, Java, C# — whatever your team already knows:

# Python (Flask) — return HTML, not JSON
@app.route('/api/users')
def get_users():
    users = db.query(User).all()
    return render_template('partials/user_list.html', users=users)

<!-- user_list.html — a partial HTML fragment -->
{% for user in users %}
<tr>
  <td>{{ user.name }}</td>
  <td>{{ user.email }}</td>
  <td>
    <button hx-delete="/api/users/{{ user.id }}"
            hx-target="closest tr"
            hx-swap="outerHTML">
      Delete
    </button>
  </td>
</tr>
{% endfor %}

No JavaScript to write. No build step. No npm packages. Your server renders HTML partials, and HTMX swaps them in. For teams with strong backend skills and modest frontend requirements, this is a significant productivity gain.

If you do need a build tool for React, see our comparison of Vite vs Webpack — Vite's 300ms HMR vs Webpack's 18 seconds is a game-changer for React development speed.

When React Is the Wrong Tool

React is overkill for:

• Content-heavy websites — blogs, documentation, marketing pages. Static site generators or HTMX handle these better.
• Simple CRUD applications — if your app is forms and tables with basic interactivity, the JavaScript overhead isn't justified.
• Server-rendered admin panels — Django Admin, Rails Admin, and similar tools work well with HTMX enhancement.
• Teams without JavaScript expertise — if your team is Python/Go/Ruby-strong, forcing JavaScript adds friction without proportional benefit.

When HTMX Is the Wrong Tool

HTMX isn't suitable for:

• Rich interactive applications — spreadsheet UIs, design tools, real-time collaboration. These need client-side state management (see our Zustand vs Redux Toolkit comparison for React state options).
• Offline-first applications — HTMX requires a server for every interaction. No server, no functionality.
• Complex client-side state — drag-and-drop builders, canvas-based editors, multi-step workflows with undo/redo.
• Mobile applications — React Native exists. There's no "HTMX Native."
• Real-time dashboards — WebSocket-driven live data visualizations need more than HTML swapping (though HTMX does support SSE and WebSocket extensions).

What's New in HTMX 2.x

HTMX 2.0 landed in June 2024, and the 2.x line has continued evolving through 2.0.4. If you're evaluating HTMX today, here's what's changed since 1.x — and why it matters.

Breaking Changes Worth Knowing

Internet Explorer support is gone. HTMX 2.0 drops IE entirely. If you still need IE, stay on 1.x (which remains supported indefinitely).

Extensions moved out of core. SSE, WebSockets, and all other extensions now live in their own repositories with independent versioning. This keeps the core bundle at 14KB and lets extensions evolve faster. You'll need to update your CDN URLs or npm imports — the old paths still work for CDN users, but migration is recommended.

DELETE requests follow HTTP spec now. In 1.x, hx-delete sent parameters in the request body (like POST). In 2.x, DELETE parameters go in the URL query string — which is what the HTTP spec actually says. If your server-side handlers expect body params on DELETE, you'll need to update them or revert with htmx.methodsThatUseUrlParams = ['get'].

selfRequestsOnly defaults to true. HTMX 2.0 blocks cross-origin requests by default — a meaningful security improvement. Your HTMX elements can only make requests to the same origin unless you explicitly opt out. For most applications, this is the right default.

New Capabilities

ESM, AMD, and CommonJS modules. HTMX 2.0 ships proper module formats (htmx.esm.js, htmx.amd.js, htmx.cjs.js), making it a first-class citizen in modern JavaScript build tools. You can now import htmx from 'htmx.org' in a Vite or webpack project without shimming.

Public htmx.swap() API. The new htmx.swap() method exposes content swapping as a public API, replacing the internal selectAndSwap(). This is useful for custom extensions and programmatic content updates — you can now swap HTML into elements from your own JavaScript code using the same engine HTMX uses internally.

Improved Web Component support. HTMX 2.x works better with Shadow DOM and custom elements, making it viable alongside Web Component libraries. The 2.0.4 release added nested shadow root fixes and proper event handling within shadow boundaries.

Patch Releases: 2.0.1–2.0.4

The minor releases have been focused on stability and edge cases:

• 2.0.2 — Fixed form boosting, file upload handling, and added the ability to trigger events on other elements via the HX-Trigger response header
• 2.0.3 — Added experimental moveBefore() support (Chrome Canary) for preserving element state during DOM moves — a significant improvement for maintaining video playback, form input focus, and CSS animations during swaps
• 2.0.4 — htmx.ajax() now defaults to targeting the body when no target or source is specified, making programmatic usage simpler

What's Coming: HTMX 4.0

Looking ahead, HTMX 4.0 (expected early-to-mid 2026) will replace XMLHttpRequest with fetch() as the core AJAX engine — what the HTMX team calls "the fetch()ening." This is a significant internal rewrite that will change the events model, since fetch() and XMLHttpRequest surface different lifecycle events. HTMX 2.x will be maintained indefinitely, so there's no pressure to upgrade.

The Middle Ground: React Server Components

React 19's Server Components blur the line. RSC renders on the server (like HTMX) but maintains React's component model and client-side interactivity where needed. It's React's answer to the "ship less JavaScript" movement.

// Server Component — zero client-side JavaScript
async function UserList() {
  const users = await db.query('SELECT * FROM users')
  return (
    <ul>
      {users.map(user => <li key={user.id}>{user.name}</li>)}
    </ul>
  )
}

Server Components don't replace HTMX's simplicity — you still need React, a build system, and JavaScript expertise. But they do address HTMX's core criticism: React apps ship too much JavaScript. For a deeper look at the meta-framework landscape, see our Astro vs Next.js comparison — Astro's "zero JS by default" approach shares philosophy with HTMX.

When to Choose React

• You're building a rich, interactive application — dashboards, editors, real-time collaboration
• You need a mobile app — React Native shares code with your web app
• Your team knows JavaScript/TypeScript — the ecosystem is massive and hiring is easier
• You need offline support — service workers and client-side state enable offline-first
• You need the ecosystem — 6,000+ npm packages, mature routing, state management, and testing tools

When to Choose HTMX

• You're enhancing a server-rendered app — add interactivity without rewriting in JavaScript
• You're building CRUD applications — forms, tables, search, and basic interactions
• Your team is backend-strong — use Python, Go, Ruby, or any server language
• Performance on low-end devices matters — 14KB beats 200KB+ on slow connections
• You value simplicity — no build step, no npm, no JavaScript framework decisions

The Verdict: HTMX vs React in 2026

React and HTMX aren't competing. They're serving different needs.

React is the right choice for complex, interactive web applications. Its ecosystem, developer tooling, and mobile story are unmatched. The JavaScript overhead is worth it when you're building software that needs rich client-side behavior.

HTMX is the right choice for server-rendered applications that need interactivity without the JavaScript complexity. It's simpler, faster to load, and lets backend teams add dynamic behavior without becoming frontend engineers.

The real question isn't "HTMX or React?" It's "how interactive does my application actually need to be?" Answer that honestly, and the choice makes itself.

Compare HTMX vs React on PkgPulse →

---

Frequently Asked Questions

Is HTMX replacing React?

No. HTMX is growing rapidly (16.8K GitHub stars gained in 2024) but serves a different use case. React is for complex interactive applications. HTMX is for server-rendered apps that need dynamic behavior without JavaScript complexity. They coexist, with HTMX growing in the server-rendered space. See the full comparison on PkgPulse for download trends.

Can HTMX do everything React can?

No. HTMX excels at server-driven interactivity — loading content, submitting forms, updating page sections. It doesn't handle complex client-side state, offline functionality, real-time collaboration, or rich interactive UIs like canvas editors or drag-and-drop builders. For those use cases, React (or similar frameworks) remains necessary.

Do I need to know JavaScript to use HTMX?

For basic usage, no. HTMX works with HTML attributes — no JavaScript required. You write your backend in any server language (Python, Go, Ruby, etc.) and return HTML fragments. For advanced patterns like custom extensions or complex event handling, some JavaScript knowledge helps, but it's optional for most applications.

Is HTMX good for SEO?

Yes. HTMX serves server-rendered HTML, which search engines can crawl and index natively — no JavaScript rendering required. React apps need SSR (Next.js, Remix) or SSG to be SEO-friendly. If SEO matters and your app is content-heavy, HTMX has an inherent advantage.

Can I use HTMX and React together?

Yes, but it's uncommon. You could use HTMX for simple pages and React for complex interactive sections. However, most teams choose one approach for consistency. A more practical middle ground is using React with Server Components, which gives you server rendering with client-side interactivity where needed.

How does HTMX compare to Alpine.js?

HTMX and Alpine.js are complementary — HTMX handles server communication (AJAX requests, HTML swapping) while Alpine.js handles client-side interactivity (dropdowns, modals, toggles). Many developers use them together: HTMX for data, Alpine.js for UI behavior.

Should I use HTMX or React for a new project in 2026?

It depends on your project's interactivity needs. For content sites, admin panels, and CRUD apps — choose HTMX. For complex SPAs, real-time dashboards, and mobile apps — choose React. For something in between, consider Next.js with React Server Components, which bridges server-rendered and client-side approaches.

---

Related Reading

• HTMX vs Alpine.js 2026 — How HTMX compares to another lightweight alternative
• React vs Vue 2026 — The other major framework comparison
• Preact vs React 2026 — A lighter React-compatible alternative
• Astro vs Next.js 2026 — Zero-JS-by-default vs full-stack React
• Vite vs Webpack 2026 — Build tool comparison for React projects
• Bundle Size Matters More Than Framework Choice — Why payload size drives real-world performance
• Best React Component Libraries 2026 — Top UI libraries for React projects

Compare HTMX vs React live data on PkgPulse →