htmx vs React: 14KB vs 200KB+ — Do You Still Need a JS Framework?

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

Originally published on pkgpulse.com

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.

At a Glance: The Numbers

Metric	React	HTMX
Weekly Downloads	96M	94K
GitHub Stars	234K+	42K+
Stars Gained (2024)	~12K	~16.8K
Bundle Size (min+gzip)	42KB (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.org-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.

Bundle Size and Initial Load

The numbers here are stark.

Metric	React (typical app)	HTMX
Framework size	42KB (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.

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.

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.
• 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).

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.

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

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 →

---

Try the full comparison at PkgPulse. Free, no signup.

Have you used HTMX in production, or is React still your go-to for everything? What's your threshold for "needs a JS framework"? Would love to hear in the comments.