The downside being, naturally, that every single interaction requires a separate round-trip HTTP request, and a web backend that is far more stateful/sessionful than would otherwise be necessary.
To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.
Quite the opposite, at least in some cases. The state lives in the HTML itself, and actual dev reports of large systems rewrites from react to htmx show faster systems as a result, not slower. In practice, it depends on what you're doing with it -- there isn't one right answer for all systems.
> every single interaction requires a separate round-trip HTTP request
Why? It's not like JavaScript stopped existing. If you need something more interactive or dynamic, use JS. The two approaches are not exclusive. Some things can go to the server and some stay in the client. Your use case determines the balance. Easy.
Yes, I don't get why people always tend to drift into thinking in extremes when it comes to new tech. Like when using htmx or similar tech you would absolutely need to implement every piece of logic in the backend.
Well, you don't. I have been very successful using htmx by using it only in interactions that make changes to my data, that is state. Other user interactions (e.g. strictly visual interactions) remain on the client.
Retuning the data as a json object vs sending it back with the relevant html really isn’t that much more data in the grand scheme of things. It’s more data but not very much, it’s not like you don’t need to sync with the backend with a json driven SPA.
Disclaimer, I converted some demo react app to htmx as a learning tool.
I reduced data transmission by about 20 percent. Cut the time to first render of html in half.
Power usage on the client was down ( probably because the test suite finished sooner) and the server was also lower, but likely for the same reason.
The html returned by the demo and my app was identical except for the react lib and htmx library. The selenium test suite only needed minor changes to work with htmx, I tried to keep the layout the same.
I can't speak for the developer experience or time spent writing the react version, but the htmx was not too painful.
I'm not sold in the fact that it doesn't matter in the grand scheme of things.
I should probably spend some time and make a blog post so that people can pick it apart and tell me how bad I am at doing it the react way.
To some extent I can see the appeal for rapid prototyping, especially for those less familiar with JavaScript. In a production environment- especially a bandwidth-limited, high-latency environment like a mobile device- it incurs an outrageous overhead on end users and server resources for that developer convenience.