Htmx: I feel sorry for you

React: I don’t think about you at all

A HTMX-y app will typically be a fetch-heavy app. Think TODO list, where each time you add a todo, you want that persisted on the server anyway. Yes you are sending more down the wire. I doubt rendering a partial HTML template is that much more work than formatting JSON but there is more crap to send down the line for sure.

Where the application is doing lots of micro-level stuff, like maybe you are drawing on a canvas and occasionally sending a payload of updates to a server, I think then HTMX would be much slower and clunkier, and that is when you dust off your React.

But you're still doing the work. With React, you render in the client. With HTMX, you split rendering between client and server.

Not really, all the rendering is done in the server.

All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM.

> All HTMX is doing is fetching HTML snippets from the backend and patching them onto the DOM.

That's how it should work, although you can get easily get around that and tack on client side rendering.

Render is a different thing in both places. Server Renders is ... formatting a sequence of bytes. Hopefully your templating engine is optimized and it is a low cost operation. Rendering on the client is obviously more involved as it requires actual rendering on the screen using the graphics drivers.

On the other side of the scale, React has overheads like a virtual dom.

It is a complicated question as to what is most performant, who bares that cost, and so on.

I'm not talking about most performant. Neither HTMX nor React has a performance issue.

The issue is overhead and complexity for the developer, and maybe, server costs.

React comes out ahead in server costs, since doing work on the client is very cheap (provided there isn't a performance issue that turns users off, which there isn't).

And in terms of dev time, it depends, but you can't say "look, with HTMX you can avoid code" because you still do need to write code, but now it's in the server.

Server rendered content has had 25+ years of development and the approaches and constraints are well understood. Client-side rendering has arguably had less than 10 years of development and the approaches and constraints are still fragmented and poorly understood. The maturity and simplicity of server side rendering shouldn't be underestimated.

I was writing SPAs with jQuery in 2008. By then they were already well-established. We used UI component libraries (mostly custom) on frontend and AJAX for server updates in XML/JSON format. They were hard to build compared to today, but "less than 10 years" of SPA development is simply incorrect.