We ran a React SPA admin panel for almost three years. It worked. Customers logged in, edited content, published articles. Bundle size kept creeping up. Build times kept creeping up. A new dev needed two weeks to be productive. We started skipping minor features because "the diff is too risky."

In Q3 2025 we migrated that panel to HTMX over six months, route by route. This post is the honest version of how it went — what worked, what we didn't see coming, and the numbers from running both stacks side by side across more than 200 production deployments.

The React tax in 2026

Let me get one thing out of the way: React isn't broken. It's a fine tool for the workloads it was designed for. Our admin panel was not one of those workloads. Most of our screens are forms, lists, and modal dialogs. The fanciest interaction is drag-to-reorder. The actual user count per tenant is small — usually 1 to 5 editors per site.

For that, here's what React was costing us:

• Bundle size: ~800 KB gzipped after route-splitting, three vendor bundles, three lazy chunks
• First admin login LCP: 3.0s to 3.5s depending on region (we serve from a single Istanbul edge)
• Build time: 90 seconds for production, 8 seconds for dev rebuild
• Onboarding: new hires needed 10–14 days before they could ship a self-contained feature
• Tooling churn: in three years we went through three state management libraries and two router majors

None of these are dealbreakers in isolation. Stacked together, they made every small change expensive. We were paying SPA prices for a CRUD app.

Why HTMX caught our attention

The pitch is one line: HTMX lets any element issue an AJAX request and swap the response into the DOM. There's no client-side router, no virtual DOM, no build step required. You render HTML on the server (we use Smarty 5), the browser swaps fragments, the network does the heavy lifting.

What sold us wasn't the elegance of the demo. It was a 40-minute spike where one engineer rebuilt our "edit article" screen — form, validation, autosave, image upload — in 180 lines of HTML + a thin PHP controller. The React version was 1,400 lines across 9 files.

The interesting part: the HTMX version felt faster, and was. No JS bundle to parse, no hydration step. The TTI was essentially the same as the LCP because there was nothing to hydrate.

Migration strategy: parallel routes, no big bang

We've been burned by big-bang rewrites before. This time we did parallel routes:

1. Both stacks live in the same admin panel. Old routes (/admin/old/*) keep serving React. New routes (/admin/*) serve server-rendered HTML with HTMX.
2. A shared session cookie means a user can be in the middle of editing in React, click a sidebar link, and land in the HTMX side without re-authenticating.
3. We migrated one feature per sprint, easiest first (read-only lists), hardest last (the article editor with WYSIWYG).
4. After each feature shipped, we deleted the React route and the JS that supported it. Bundle size dropped in steps — that visibility kept morale up.
5. The cutover wasn't a date on the calendar. It was the moment the React bundle hit zero. That happened in week 22.

The "no big bang" rule matters. If we'd tried to ship the whole panel in one PR, we wouldn't have shipped at all.

Three patterns we use everywhere

Most of the panel is built from three patterns. If you understand these, you understand 80% of an HTMX codebase.

1. Form submit with inline validation

<form hx-post="/admin/articles"
      hx-target="#form-result"
      hx-swap="outerHTML">
  <input type="text" name="title" required>
  <textarea name="body"></textarea>
  <button type="submit">Save</button>
  <div id="form-result"></div>
</form>

Server returns either a success fragment or the same form re-rendered with inline error messages. No client-side validation library. No form library. The server is the single source of truth.

The win: we deleted ~5,000 lines of duplicated client-side validation that was always one schema change away from drifting from the server.

2. Infinite scroll for long lists

<div id="article-list">
  <article>...</article>
  <article>...</article>
  <div hx-get="/admin/articles?page=2"
       hx-trigger="revealed"
       hx-swap="outerHTML">
    Loading...
  </div>
</div>

The sentinel div triggers when scrolled into view, fetches the next page, and replaces itself with the next batch (plus a new sentinel). One pattern, every long list. No virtual scrolling library, no IntersectionObserver setup code in userland.

For lists over ~10,000 items we still reach for virtual scrolling, but those are rare in an admin context.

3. Modal dialogs with hx-target

<button hx-get="/admin/articles/42/edit"
        hx-target="#modal"
        hx-trigger="click">
  Edit
</button>

<div id="modal"></div>

The server returns the modal markup including a <dialog> element with open. To close, the modal posts back and returns an empty fragment that replaces itself. State of the dialog lives on the server.

This one took the longest to internalize. The instinct from React land is to manage modal state in a store. With HTMX, the modal is just a fragment of HTML that the server hands you when you ask for it.

The numbers, after six months

A few things worth calling out:

The 50 KB on the HTMX side is HTMX itself plus a tiny amount of our own glue code (~600 lines). No build pipeline required, though we keep a Vite step for CSS bundling.

Backend response time went up. That's not free — server rendering moved work from the client to the server. We mitigated with aggressive caching of partials (Smarty + Redis), but the trade is real: you pay in server CPU what you save in client work.

The LOC drop surprised us. We expected maybe 10–15%. The 33% came mostly from deleting client-side mirrors of server state — form models, validation, optimistic update logic.

Where HTMX falls short — real talk

This is the section I wish more "we switched to X" posts included.

Offline support is gone. If you need a panel that works on a flaky connection, HTMX is the wrong tool. Every interaction is a network round-trip.

Complex client interactions get awkward. We have one screen — a drag-and-drop tree editor for category hierarchy — that's still React. HTMX can do drag-and-drop with sortable.js, but the round-trip-per-drop model breaks down for fine-grained interactions. Use the right tool.

Optimistic UI requires effort. In React we'd just update local state and roll back on error. With HTMX you can simulate this with hx-swap-oob and some discipline, but it's more code, not less.

Backend team needs to care about HTML. This sounds obvious, but if your backend devs have been shipping pure JSON for five years, the switch to "you also own the fragment markup" is a real culture change. Some loved it. Some resisted.

Browser DevTools are less helpful. No component tree, no React DevTools. You're back to inspecting the DOM and reading network requests. After a week we stopped missing the component tree, but the first week was rough.

Testing changed. We dropped React Testing Library and most Jest tests. We added more PHP integration tests that fetch endpoints and assert on the returned HTML. Total test count went down ~40% but coverage actually improved — we were testing implementation details before.

Was it worth it?

For a CRUD admin panel with a small concurrent user count, serving server-rendered HTML over the wire and letting the browser do what the browser is already good at — yes, very much.

The cost shifted: we moved complexity from the client to the server, which means we now care more about backend cache hit rates and partial rendering performance than about React render performance. That's a tractable problem for the team we have.

We're not evangelists. The frontend team kept React for our customer-facing storefront editor, where rich interaction and offline-first matter. The right architecture is the one that fits the workload.

If you're sitting on a React-built admin panel that feels heavier than the problem it solves, do a one-week spike on the smallest screen. Measure. If the numbers above look like yours, you might save more by deleting code than by writing it.

This is part of an engineering blog series from Alesta WEB, where we build news CMS and e-commerce platforms used by 200+ production sites in Turkey. Other posts cover our multi-LLM CMS architecture and more.