Comment by cies

> htmx is much easier for the developer, but worse for the user because of higher latency for all actions

Latency is something to consider yes. Besides that we should not forget it is easy to make an HTMX-mess: HTMX's not a good fit not fit for all use-cases and some approaches are dead end (the article even talks about this, but you find more testimonies of this online). With HTMX you also create a lot of end-points, usually without a spec: this can also become an issue (might not work for some teams).

> if you mix client- and server-side computation, then you're adding back in complexity that you explicitly wanted to get away from by using htmx.

Exactly! A good reason not use HTMX, if you need a lot of browser-side computation.

> I didn't mean (just) that. I included vanilla webtech in my definition of "normal"

If you mean "just scripting with JS (w/o any framework)" then I still do not think this is an acceptable alternative to compare HTMX to. IMHO you have to compare with something that that provides a solid basis to develop a larger application on. Otherwise you may say HTMX is great because the status quo (vanillaJS/React/Vue/Ang) is such a mess.