Confession: I spent about a year telling people they should try htmx and refusing to actually rewrite anything of my own in it. That’s a very online kind of hypocrisy, and I decided to fix it earlier this year.<\/p>\n
I’ve now shipped two internal tools with htmx as the main frontend, kept most of my client-heavy stuff on React 19, and I think I finally have a real opinion about when each one deserves the job.<\/p>\n
Short version for the impatient: if the page is mostly forms and lists, htmx is embarrassingly good. If the page is a live editor, a chat surface, a canvas, or anything with a lot of client state, keep using React. If someone tells you htmx is a “React replacement,” they’ve never shipped either one.<\/p>\n
Here’s the long version.<\/p>\n
Fast recap so we’re not arguing past each other. htmx is a small JavaScript library that lets you drive AJAX requests, WebSocket messages, and DOM swaps from HTML attributes. You write It is not a component framework. It doesn’t manage client state. It doesn’t diff a virtual DOM. It doesn’t understand JSX.<\/p>\n It is not a backend. Something on the server has to return the HTML fragments. That’s your Laravel, Rails, Express, Go net\/http, whatever.<\/p>\n It is not a replacement for React on interfaces that are genuinely apps. If your users spend an hour a day inside a canvas with dragging, panning, and undo, please stop reading and go back to React.<\/p>\n If you have those expectations calibrated, everything else about htmx makes more sense.<\/p>\n Here’s “click a button, load the next page of posts, append it to a list.” The classic infinite-scroll pattern.<\/p>\n React (with fetch + state, no libraries beyond React 19):<\/p>\n You’ve written three pieces of state, a fetch, a JSON parse, and a re-render. It works. It’s also the sort of code that used to embarrass me a bit until I stopped noticing.<\/p>\n Same thing with htmx, where the server returns HTML fragments:<\/p>\n Your server route responds with Now, which of those is “better?” It’s the wrong question. The right question is which one is going to be easier to maintain three years and two developers from now.<\/p>\n Server-rendered apps with sprinkles of interactivity are its native habitat. Admin panels, CRUD dashboards, marketing sites with a contact form. If more than 80% of your page transitions used to be full-page reloads that just replaced some markup, htmx replaces those with partial swaps and you delete a lot of code.<\/p>\n Backends that already generate HTML well are the second win. Laravel Blade, Rails ERB, Django templates, Go html\/template. You’re already good at this. You’ve already got the layout tests. Reusing that engine and letting htmx do the swapping is a fast payoff.<\/p>\n Tiny teams matter here too. htmx doesn’t need a build pipeline. There’s no Vite config, no bundler, no bundle-size budget. You add one script tag. If your team is one person, this compounds quickly.<\/p>\n I have a small internal tool for triaging bug reports that used to be a React SPA. I rewrote it in Laravel plus htmx in a weekend and deleted about 60% of the code. It’s not fancier. It’s just done, and I never think about it. I write a bit more about that kind of trade-off in the notes on my portfolio site<\/a>, which is itself a boring server-rendered thing that I do not miss making into an SPA.<\/p>\n Real-time collaborative UIs are React’s home turf. Multiple cursors, shared canvases, presence indicators. htmx can drive WebSocket messages, but any time you have complex client state that needs to reconcile with incoming events, React’s model is a better fit.<\/p>\n Forms with rich, interdependent client-side validation are another React sweet spot. The multi-step, cross-field, “if this then that” wizards. You can build these in htmx, but you’ll be reinventing form state management. I’ve written about how much cleaner these flows got with newer React primitives, especially React 19’s Suspense in production<\/a> and the React 19 release notes on Anything with a lot of local, ephemeral state also wants React. Text editors, live filters over big client-side lists, drag-and-drop grids. htmx wasn’t built for these, and pretending otherwise gets you into trouble by month two.<\/p>\n If your users spend most of their session inside one screen doing dozens of small interactions per minute, you probably want React. If they mostly move between pages that show them information and take input, you probably want htmx.<\/p>\n The htmx marketing tends to emphasize “ship less JavaScript.” That’s true. My rewritten internal tool ships about 14KB of htmx and no other JS, versus roughly 180KB of React plus client bundles before. On a fast desktop over fiber, nobody notices. On a mid-range Android over a wobbly LTE connection, it’s the difference between a page you can use and a page you close.<\/p>\n But, and this is the honest part, a well-configured React app with server components, streaming, and smart code-splitting is fine on the same network. The gap is real, it’s just smaller than the htmx-vs-React essays tend to imply. I keep a small benchmark suite on my machine and the median LCP difference for an equivalent CRUD page is around 300ms in htmx’s favor. That matters. It’s not a factor-of-10 win.<\/p>\n If you’re trying to talk your team into htmx, don’t lead with “React is bloated.” Lead with “we have three developers and this page reloads five times a day.”<\/p>\n htmx: the page is mostly forms, lists, and server-rendered content, and interactivity is the exception rather than the default.<\/p>\n React: the page is an application, client state is real, and the users treat it more like a tool than a document.<\/p>\nhx-get<\/code>, hx-post<\/code>, hx-target<\/code>, and your server returns HTML fragments that htmx patches into the page. The htmx docs<\/a> call it “high power tools for HTML.” I keep calling it “server-rendered HTML that finally got tired of jQuery.”<\/p>\nThe 30-second comparison in code<\/h2>\n
function PostList() {\n const [posts, setPosts] = useState([]);\n const [page, setPage] = useState(1);\n const [loading, setLoading] = useState(false);\n\n async function loadMore() {\n setLoading(true);\n const r = await fetch(`\/api\/posts?page=${page + 1}`);\n const j = await r.json();\n setPosts([...posts, ...j.posts]);\n setPage(page + 1);\n setLoading(false);\n }\n\n return (\n <>\n <ul>{posts.map(p => <li key={p.id}>{p.title}<\/li>)}<\/ul>\n <button onClick={loadMore} disabled={loading}>\n {loading ? "Loading..." : "Load more"}\n <\/button>\n <\/>\n );\n}\n<\/code><\/pre>\n<ul id="posts">\n <li>First post<\/li>\n <li>Second post<\/li>\n<\/ul>\n\n<button\n hx-get="\/posts?page=2"\n hx-target="#posts"\n hx-swap="beforeend"\n hx-indicator="#spinner"\n>\n Load more\n<\/button>\n\n<span id="spinner" class="htmx-indicator">Loading...<\/span>\n<\/code><\/pre>\n<li>Third post<\/li><li>Fourth post<\/li><\/code>, htmx appends them, done. There’s no client state to worry about. The URL of the button already documents what it does.<\/p>\nWhere htmx quietly wins<\/h2>\n
Where React (still) wins<\/h2>\n
use()<\/code> and Actions<\/a>, and the ecosystem is genuinely built for this shape of problem.<\/p>\nPerformance and the “less JavaScript” pitch<\/h2>\n
When to reach for which, one line each<\/h2>\n