Huh, so every interactive event has a network request in the loop, with perceptible latency? And you still end up obligating client-side JS for the plumbing? I'd been meaning to look into HTMX but based on the content of this post it seems like a worst-of-all-worlds technical solution. Is it at least pleasant to work with?
No, every interactive event doesn't need to have a network request in the loop. And you only need a tiny bit of client-side JS for a most of the plumbing.<p>It is quite pleasant to work with, because you don't have to worry about a constant stream of vulnerabilities or supply chain attacks. You just vendornthe script in your repo, add it as a <script> tag on the page, and you're done.
That's why many times HTMX is used together with alpinejs [1].<p>For areas that need server side, if you use say react and return a JSON you have to deserialize and do the render. It might be much more efficient to just replace.<p>Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.<p>[1] <a href="https://alpinejs.dev/" rel="nofollow">https://alpinejs.dev/</a>
It's for building extremely backend-brained frontend stuff, like a sort of anti-NextJS. Also like NextJS, this sort of domain-bending has some unfortunate operational consequences.
It’s only has a network request in the loop if the interaction requires a network request.<p>Htmx is a replacement for network interactions, not every bit of UI interactivity.
the network is faster than so much shitty client-side JS these days.