Single Page Applications became the default architecture for web applications around 2013-2015. React, Angular, Vue - the assumption was that if you wanted to build a serious web application, you built a SPA with a JSON API and a JavaScript frontend that managed all UI state.

HTMX, a small JavaScript library, challenges this assumption not by adding more JavaScript but by removing the need for most of it.

The argument is worth taking seriously.

What HTMX Actually Does

HTMX extends HTML with attributes that let any element make HTTP requests and replace parts of the page with the server’s response. This is it. There is no JavaScript to write.

<!-- A button that loads content from the server -->
<button hx-get="/api/users" hx-target="#user-list" hx-swap="innerHTML">
  Load Users
</button>

<div id="user-list"></div>

When the button is clicked, HTMX makes a GET request to /api/users. The server returns HTML. HTMX replaces the #user-list div’s content with that HTML.

The key property: the server returns HTML, not JSON. The server renders the view. The browser receives pre-rendered HTML fragments and inserts them.

This is not a new idea. It is how the web worked before JavaScript frameworks. HTMX’s innovation is providing a clean, attribute-based interface to this pattern that feels modern.

The SPA Architecture Tax

To understand why HTMX has found an audience, you need to understand what SPAs require.

A standard React SPA requires:

  • A build system (Webpack, Vite, etc.)
  • A state management library (Redux, Zustand, Jotai, etc.)
  • A routing library
  • A data fetching library (React Query, SWR, etc.)
  • TypeScript configuration
  • A separate API server
  • JSON serialization/deserialization on both ends
  • Loading states for every async operation
  • Error handling for network failures
  • Optimistic updates if you care about UX

Each of these is a legitimate engineering decision. Together they represent a significant complexity overhead that every SPA pays regardless of the application’s actual complexity.

For a simple CRUD application - displaying records, editing them, deleting them - this overhead is disproportionate. The application’s logic is not complex. The infrastructure to support it is.

The HTMX Counter-Argument

HTMX’s argument, made most forcefully in the “HTMX Essays” and the book “Hypermedia Systems,” is that REST was originally conceived as a hypermedia architecture and that JSON APIs represent a departure from the original vision.

REST (Representational State Transfer) as described by Roy Fielding specified hypermedia as the engine of application state (HATEOAS). The client receives hypertext (HTML) with links and forms that describe what actions are possible. The client does not need out-of-band knowledge of the API.

JSON APIs broke this model. The client and server became tightly coupled: the client needs to know the API’s URL structure, the shape of the JSON responses, and how to render that JSON into UI. None of this information comes from the server.

HTMX returns to the hypermedia model. The server controls the UI by returning HTML. Navigation and interaction are described in the HTML itself. The client (browser + HTMX) is generic.

When HTMX Makes Sense

HTMX shines in specific categories of applications:

Admin interfaces and internal tools. These are typically CRUD applications: create records, list them, filter, edit, delete. The interactivity requirements are moderate. The developer time spent building a React SPA for an admin panel is often excessive relative to the value.

Content-heavy applications. Blogs, documentation sites, news sites - applications where most interactions are navigation and simple filtering. Server rendering is the natural fit.

Applications with complex backend logic. When most of the interesting logic is server-side (authorization rules, business logic, database queries), keeping the rendering server-side avoids duplicating that logic in a client-side state machine.

Small teams with full-stack developers. When one developer builds both backend and frontend, the context switching cost of maintaining a separate SPA is high. HTMX lets a backend developer add interactivity without becoming a React specialist.

Where HTMX Falls Short

HTMX is not a universal replacement for SPAs.

Rich client-side state. Applications like collaborative editors, complex forms with conditional logic, or real-time multiplayer experiences manage significant client-side state that needs to react instantly to user input without a server round-trip. HTMX’s server-round-trip model is the wrong architecture here.

Offline capability. If your application needs to work without network connectivity - Progressive Web Apps, mobile-first apps with offline mode - you need client-side state management that HTMX does not provide.

Complex animations and transitions. HTMX swaps DOM content. Complex animated transitions between states require either CSS transitions on HTMX swaps (which work for simple cases) or JavaScript (which adds complexity back).

Performance for high-frequency interactions. If user actions trigger updates many times per second - dragging, live search as you type, real-time data visualization - the server round-trip latency in HTMX becomes perceptible.

The Adoption Reality

HTMX is not growing into the React ecosystem’s territory. It is occupying a different space: applications that should never have been SPAs.

The interesting trend is not individual developers choosing HTMX. It is frameworks integrating HTMX as a first-class option:

  • Django’s HTMX integration libraries have become popular
  • Rails has HTMX integration patterns that feel native
  • Phoenix LiveView (an Elixir framework) takes a similar server-sends-HTML approach and has been influential

The validation is the growing recognition that “SPA for everything” was overcorrection, and that there is a large category of applications better served by server-rendered HTML with targeted JavaScript for interactive components.

The Hybrid Approach

The pragmatic architecture for many applications:

  • Server-rendered HTML with HTMX for navigation, CRUD operations, and standard interactions
  • JavaScript components (React, Vue, or Svelte) only for genuinely complex, stateful UI (rich text editors, charts, real-time features)

This is “islands architecture” - rendered HTML with interactive JavaScript islands where needed. Astro popularized this for content sites. The same principle applies to application development.

Bottom Line

HTMX challenges the SPA orthodoxy by demonstrating that hypermedia-based HTML responses from the server can handle a large percentage of web application interactivity without the complexity tax of full SPA architecture. It is the right choice for CRUD applications, admin interfaces, and applications with primarily server-side logic. It is the wrong choice for rich client-side state, offline capability, and high-frequency real-time updates. The most important shift HTMX has driven is forcing the industry to ask “does this application actually need to be a SPA?” - and more often than expected, the answer is no.