Bravo! I never would have thought this would be so simple. As a direct consequence of this exercise: I now know something about what, precisely, htmx does.
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.
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].
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.
Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.
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.
We already have the naughtiest htmx
https://github.com/bigguysoftware/htmxxx
Bravo! I never would have thought this would be so simple. As a direct consequence of this exercise: I now know something about what, precisely, htmx does.
cheers
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.
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].
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.
Having said that I use HTMX /alpinejs for small projects, and still trust react for bigger more interactive ones.
[1] https://alpinejs.dev/
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.
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.
The Github link at the bottom contains a `,` char, might want to fix it.