HTMX in production: where it works and where it falls apart

HTMX has been around since 2020, but the spike in attention came in 2023-2024 on the wave of React fatigue. By 2026 that wave has settled into a quiet background: the library is stable on 2.x, maintained by a small team led by Carson Gross. We have three live HTMX projects in the studio and two more we considered and dropped. Sharing that experience.

What HTMX is, briefly

The idea is simple. Put an attribute like hx-get="/items" on any HTML element. On click, the browser sends a request. The server returns HTML, not JSON, and the library inserts the fragment into the DOM at the target location. You render the same way you did in 2010 — server-side, via templates — but without full page reloads.

This is not React or Vue. State lives on the server, client JS is minimal. To add richer interactions, HTMX is usually paired with Alpine.js or Hyperscript, with the main language remaining server-side: PHP, Python, Go, Ruby.

Case 1: customer portal for a CRM (PHP + HTMX). Worked great

A six-week project: customer portal for a beauty salon chain, on top of an existing PHP backend. Service cards, visit history, rebooking. No offline, everything driven from the admin panel.

HTMX was an ideal fit. Frontend JS came in at around 120 lines for the entire portal. The backend reused the same templates as the admin panel. Development time was about a third shorter than going SPA. Page load time was 200ms because there is no fat bundle.

Forms were the biggest saver. With HTMX a form posts via hx-post and returns an updated chunk of the page. No need to write client validation, then server validation, then synchronise them — write it once on the server.

Case 2: logistics dashboard (Python + HTMX). Things diverged

Internal tool for dispatchers. Map, order list, filters, drag-and-drop across statuses, real-time updates. Initial idea: HTMX, to avoid pulling in React.

Within two weeks we hit walls:

• Drag-and-drop — HTMX is useless here. We wrote it in plain JS on top of SortableJS and synced with the server via hx-put
• Complex filters — several checkboxes, a date range, search. In HTMX every filter change is a separate request. The user clicks five checkboxes, that is five requests. You can debounce, but the latency is noticeable. With local React state, this is instant
• Real-time over SSE — HTMX 2.0 supports Server-Sent Events natively, and it works. But updating 50+ cards through server-rendered HTML is heavy on both server and DOM

We ended up with a mixed architecture: HTMX for forms and navigation, React islands for the map and the filtered list. It works, but it is a Frankenstein. Pure HTMX would not have carried this case.

Case 3: landing page with an order builder (Go + HTMX). Ideal

An equipment rental service: users pick items, days, delivery, see the price. All the interactivity is selecting variants, adding line items, changing quantity. No state that needs to survive a reload.

HTMX covered everything. Server code was ~600 lines of Go, frontend ~30 lines of JS (only for small UX touches like autofocus). TTFB under 100ms because the server just renders templates. SEO works out of the box — every page is HTML that both users and search engines see.

When HTMX is the right call

• Admin panels, customer portals, dashboards with tabular data
• Landing pages with multi-step forms and selectors
• CMS-like tools with lots of forms and little drag-and-drop
• Internal tools for teams up to 50 people, where development speed beats wow factor
• Projects where SEO is critical and bundle redeploys are not desired

When the wall hits

• Rich client state that changes without server interaction
• Highly interactive UIs: drag-and-drop, editors, canvases
• Offline-first apps, PWAs with local databases
• Real-time with dozens of simultaneous updates
• Projects where the frontend team is stronger than the backend team and wants to live in the JS ecosystem

What we learned

Main lesson: HTMX is not a "new React paradigm," it is a return to server rendering with a thin JS overlay. If your backend is solid — the win is huge. If the backend is weak or the team does not enjoy server-side work — it will hurt.

Second lesson: do not try to do everything in HTMX. A mixed architecture (HTMX + Alpine + React islands where complex) works better in practice than pure HTMX forced into shapes it was not designed for.

Third: the team. HTMX appeals to people who remember 2010s server templating. Younger frontend engineers raised on React tend to write HTMX like a "poor React" and damage the architecture. Budget a week to shift the mental model when bringing a frontend-heavy person onto HTMX.

Forecast for end of 2026

HTMX will not become "the new standard," and nobody is positioning it that way. It is a niche tool growing roughly 30-40% year over year in job postings and npm dependencies, and it fits a specific shape of project comfortably. The hype is gone, what remains is a quiet, working technology. Honestly the best possible outcome for a new web framework.