Sometime around the middle of last year we stopped reaching for React on small-business projects. It wasn't a manifesto. It was a Tuesday in October, an estimate that came out cheaper without the build pipeline, and a client who didn't care which framework we used as long as the contact form posted. That client launched in three weeks. The next one took two.

We've now shipped fourteen sites on htmx. We'd ship the fifteenth tomorrow.

The case against React for our size of project was never really technical. We could build anything in React. The problem was everything around it: the build chain, the version churn, the steady low-grade tax of keeping a project compilable a year after launch. A static brochure site with a quote form does not need server components. It does not need streaming SSR. It needs HTML that arrives quickly and stays out of the way.

What htmx gets right

You write hx-post on a button. The server returns a fragment of HTML. The fragment replaces a piece of the page. That's it. There is no virtual DOM, no hydration mismatch, no client-side state library, no useEffect cleanup, and no ongoing debate about whether something should be a server component or a client component. The mental model is the one the web shipped with in 1996, just with the rough edges sanded down.

The HTML-over-the-wire approach also means most of your stack stops mattering. Our last three htmx projects used three different backends (Go, Rails, and a Cloudflare Worker with D1). The frontend was the same in all of them. That's a portability you do not get when your stack assumes React on the client.

Where it stops working

Anything that genuinely needs client-side state across many components. A live dashboard with cross-cutting filters. A drag-and-drop builder. A complex form wizard with conditional fields that talk to each other. We still reach for React or Vue on those, and we should. But that's maybe 15% of our work. The other 85% is "the page needs to do a thing when the user clicks the button," which htmx handles in eight lines of HTML.

The migration cost is also lower than people think. We took an older client site off Gatsby last quarter — a static blog with maybe forty posts. The replacement was a Hugo build plus htmx for the comment form. Three days of work. Build time dropped from 90 seconds to under two. The client doesn't care about any of that, but the next time they want a small change, we don't need to spend an hour reminding ourselves how the project's dependencies wire together.

A few practical notes from the trenches

The HTML payload is bigger than a JSON payload. This matters more in theory than in practice on the connections we see, but if you're targeting users on slow mobile in markets where bandwidth costs real money, profile before assuming. We saw a 12 KB to 28 KB swap on one page and the user didn't notice. We'd have noticed on a site doing a million views a day.

You will still write JavaScript. htmx is not "no JavaScript." It's "less JavaScript, for less of the page." We use Alpine.js alongside it for the places where genuine client state matters — a dropdown that opens, a tab that switches. Together they cover maybe 95% of what we used to reach for React to do.

Caching gets weird. If you're returning HTML fragments from API routes, your CDN strategy has to think in fragments. Most of our clients don't have CDNs aggressive enough for this to bite, but if yours does, plan for it.

SEO is fine. The initial page is server-rendered HTML. Subsequent fragments don't get crawled, but they're typically the kind of interactive content that doesn't need to be — filtered product lists, form responses, that sort of thing. We've seen no ranking changes on any site we've moved.

The argument I'll defend hardest

The pitch for React was always that it makes complex UI tractable. That pitch is still correct for complex UI. But somewhere between 2018 and 2024 the floor for "you have to use React" dropped to "your landing page needs a contact form," and a lot of small shops paid the build-pipeline tax for years without the complex UI ever materializing. We were one of them. We were wrong.

If you're picking a stack for a small-to-medium business site right now and someone tells you React is the safe default, ask them what they're hedging against. Sometimes the answer is good. More often it's a habit nobody examined.