HTMX vs React: When Less JavaScript Is the Right Choice

HTMX gained massive traction in 2025 and 2026 as the "anti-React" movement. Its premise is simple: instead of building a JavaScript SPA that fetches JSON from an API and renders it client-side, return HTML fragments from the server and swap them into the page. No virtual DOM, no build step, no hydration, no bundle size anxiety.

HTMX is a 14KB JavaScript library. It adds attributes to HTML elements that trigger HTTP requests and insert the response into the DOM. hx-get, hx-post, hx-swap, hx-trigger. That is 90% of the API. A developer who has never seen HTMX can read an HTMX page and understand what it does. That is not true of a React codebase.

The argument for HTMX is not that React is bad. React is excellent for highly interactive applications (Figma, Notion, Google Docs). The argument is that most web applications are not Figma. Most web applications display data, handle forms, and navigate between pages. For those applications, the SPA approach adds complexity without proportional benefit.

HTMX is not new technology. It is a return to the original web architecture (server renders HTML, browser displays it) with modern UX touches (partial page updates, transitions, form validation). The question is not whether HTMX works. It does. The question is whether it works for your specific product.

HTMX extends HTML with attributes that make any element trigger HTTP requests:

Basic example: A button that loads search results without a full page refresh:

Your server returns an HTML fragment (just the search results, not the full page). HTMX swaps that fragment into the target element. No JavaScript written. No state management. No JSON serialization/deserialization.

Key HTMX Attributes

• hx-get, hx-post, hx-put, hx-delete: Trigger HTTP requests from any element (not just forms and links).
• hx-target: Which DOM element to update with the response.
• hx-swap: How to insert the response (innerHTML, outerHTML, beforeend, afterbegin, etc.).
• hx-trigger: What event triggers the request (click, submit, keyup, intersect for lazy loading, every 5s for polling).
• hx-indicator: Show a loading spinner while the request is in flight.

Server-Side Rendering

Your server returns HTML, not JSON. Any server framework works: Django, Rails, Laravel, Express with a template engine, Go with html/template, Phoenix LiveView. This means you can use the language and framework your team already knows. No React, no JSX, no build pipeline, no Node.js required on the server.

The simplicity is the point. A full-stack developer can build a complete HTMX application without touching package.json, webpack, Vite, or any JavaScript build tool.

HTMX's performance advantage comes from shipping dramatically less JavaScript to the browser.

Bundle Size Comparison

• HTMX: 14KB (minified, gzipped). That is the entire framework.
• React + ReactDOM: 42KB (minified, gzipped). Before your application code.
• Next.js: 80 to 150KB of framework JavaScript. Before your application code.
• A typical React SPA: 200 to 500KB total JavaScript. Sometimes much more.

Less JavaScript means faster Time to Interactive. Mobile devices spend significant time parsing and executing JavaScript. A 300KB JavaScript bundle takes 1 to 2 seconds to parse on a mid-range Android phone. HTMX's 14KB parses in under 50ms.

Core Web Vitals

HTMX applications consistently score higher on Core Web Vitals because there is no hydration step (the HTML is interactive as soon as it arrives), less JavaScript means less main thread blocking (better FID/INP), and server-rendered HTML provides instant LCP. For an in-depth guide on optimizing these metrics, see our Core Web Vitals optimization guide.

The Latency Tradeoff

HTMX makes more server requests than a SPA (every interaction hits the server). If your server is fast (under 50ms response time), users do not notice. If your server is slow or far from the user, the extra round trips add up. This is the primary performance tradeoff. SPAs can feel snappier for interactions that use already-loaded data. HTMX feels snappier for initial load and navigation.

HTMX excels for specific types of applications. Here is where it genuinely beats React:

Content-Heavy Websites

Blogs, documentation sites, news sites, e-commerce product pages, and marketing sites. These are fundamentally server-rendered content with sprinkles of interactivity (search, filtering, add to cart, comment forms). HTMX handles these interactions without the overhead of a SPA framework.

Admin Dashboards and Internal Tools

CRUD interfaces, data tables with sorting and filtering, form-heavy workflows, and report generators. These applications have well-defined interactions (load data, display it, edit it, save it) that map perfectly to HTMX's request-response model. Django + HTMX or Rails + HTMX is a potent combination for admin tools.

Multi-Page Applications

Applications where users navigate between distinct pages rather than staying on a single page. E-commerce stores, SaaS products with separate settings/dashboard/reports pages, and marketplaces. HTMX provides SPA-like transitions between pages (with hx-boost) without the SPA complexity.

Small Teams with Full-Stack Developers

A single full-stack developer can build a complete HTMX application. No frontend/backend split. No API contract negotiation. No separate deployment pipelines. For a 2 to 3 person startup team, this simplicity translates to shipping faster.

Server-Side Language Preference

If your team's strength is Python, Ruby, Go, or PHP, HTMX lets you build modern web apps in your preferred language. No need to maintain a separate Node.js/React frontend. The server renders HTML, HTMX makes it interactive.

HTMX is not a universal replacement for React. Here is where React genuinely wins:

Highly Interactive UIs

Drag-and-drop interfaces, real-time collaborative editing, complex data visualizations, canvas-based tools, and rich text editors need client-side state management and manipulation that HTMX cannot provide. If your product's core value is in the interactivity (Figma, Miro, Notion, Airtable), you need React or a similar framework.

Offline-Capable Applications

HTMX requires a server connection for every interaction. If your users need to work offline (field service apps, mobile apps in areas with poor connectivity), you need client-side state management and a sync layer. React with local storage or IndexedDB handles this. HTMX does not.

Complex Client-Side State

Applications where multiple UI components need to react to shared state changes simultaneously. A trading dashboard where a price change updates the chart, the order book, the position summary, and the P&L display all at once. Client-side state management (Redux, Zustand, Jotai) handles this elegantly. HTMX would need separate server requests for each update.

Large Teams with Frontend Specialists

If you have dedicated frontend engineers, React's component model, type safety with TypeScript, and extensive testing tools (React Testing Library, Storybook) provide structure that scales with team size. HTMX applications can become hard to maintain as they grow, because the interaction logic is spread across HTML attributes and server endpoints rather than encapsulated in components.

The framework choice matrix from our React vs Vue vs Svelte comparison applies here too: match the tool to the problem.

The best architecture for many products is neither pure HTMX nor pure React. It is HTMX for most pages with islands of React (or Alpine.js, or vanilla JavaScript) for the interactive parts that need client-side state.

HTMX + Alpine.js

Alpine.js (17KB) provides lightweight client-side interactivity (dropdowns, modals, tabs, toggles) without a build step. Combined with HTMX, you get server-driven pages with client-side micro-interactions. This combination covers 90% of typical web application needs.

HTMX + React Islands

Render most of the page as server HTML with HTMX. Embed React components for specific features that need rich interactivity (a chart, a drag-and-drop board, a rich text editor). The React component mounts into a div on the page and manages its own state. The rest of the page stays server-rendered.

Progressive Enhancement

Start with a server-rendered HTML application. Add HTMX for dynamic updates without full page reloads. Add Alpine.js or Stimulus for client-side interactions. Add React only for the specific components that truly need it. Each layer adds complexity, so add them only when the simpler approach is not sufficient.

This layered approach is cheaper to build, easier to maintain, and performs better than a full SPA for most applications. And you can always migrate specific pages to a SPA later if the interaction requirements grow.

Here is a quick decision framework:

Use HTMX if: Your app is primarily CRUD operations and content display. Your team is small (1 to 5 developers). You want the simplest possible architecture. Performance and SEO are important. Your backend team is stronger than your frontend team. You are building admin tools, dashboards, or content sites.

Use React/Next.js if: Your app requires rich client-side interactivity. You need offline support. You have dedicated frontend engineers. You need extensive third-party UI components. Your product competes on UX sophistication. You are building a tool, editor, or highly interactive product.

Use both if: Most of your app is content and forms, but specific features need rich interactivity. You want fast initial development (HTMX for the common pages) with the option to add complexity where needed (React for interactive features).

HTMX is not a step backward. It is a recognition that the web's original architecture (server renders HTML, browser displays it) was actually pretty good, and that adding a 300KB JavaScript framework to display a list of products is often unnecessary.

If you are starting a new project and want help choosing the right architecture, book a free strategy call with our team. We will recommend what fits your product, team, and timeline.