Why We Switched from React to HTMX in Production: A 200-Site Case Study

After running a React SPA admin panel for three years, a team migrated over 200 production deployments to HTMX over six months, finding that React's complexity was unnecessary for their primarily CRUD-based workload of forms, lists, and modals. The HTMX version required significantly less code—for example, an "edit article" screen dropped from 1,400 lines across 9 React files to 180 lines of HTML with a thin PHP controller—and eliminated bundle size, build times, and hydration overhead. The migration succeeded by running both stacks in parallel route-by-route, avoiding a big-bang rewrite, and leveraging three core HTMX patterns (forms, infinite scroll, and server-rendered modals) that covered 80% of the codebase.

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. 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: None of these are dealbreakers in isolation. Stacked together, they made every small change expensive. We were paying SPA prices for a CRUD app. 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. We've been burned by big-bang rewrites before. This time we did parallel routes: /admin/old/ keep serving React. New routes /admin/ serve server-rendered HTML with HTMX.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. Most of the panel is built from three patterns. If you understand these, you understand 80% of an HTMX codebase. <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. <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. <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. 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. 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. 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.