[jonahx]

> This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data.

In your analogy, the client JS code is like the serverside code, fetching over the network instead of directly from the DB, and then doing essentially the same work from there... materializing html and a set of controls for the user to interact with.

In a sense, I see your point.

But there's a difference: When you materialize the html on the server and send that over the wire, the browser does all the work for you. When you take the SPA approach, you must re-implement much of what the browser does in JS, and hence the well-known trouble with routing, history, and so on. You can argue that React/Angular/whatever takes care of this for you at this point, and to some extent it's true, but you're still cutting against the grain. And even as mature as the frameworks are, you will hit weird edge cases sometimes that you'd never have to worry about with the browser itself.

[chrsjxn]

There's some difference, but I'm still not convinced. An htmx app is still using JS to manipulate the state of the DOM based on the results of API calls. You could build an app with web-components that do the same local modifications using JSON payloads.

There are definitely advantages to using a multi-page application architecture, which htmx is going to get by default.

But I really don't see a big difference between using JS to replace DOM fragments with server generated HTML, compared to using JS to replace DOM fragments with client generated HTML.