Let's make the worst Htmx
zserge.com
Let's make the worst Htmx
1–10 of 85 posts
Re: Let's make the worst Htmx
#2Bravo! 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
Re: Let's make the worst Htmx
#3Huh, 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?
Re: Let's make the worst Htmx
#4Huh, 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?
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.
Re: Let's make the worst Htmx
#5[flagged]
Re: Let's make the worst Htmx
#6Huh, 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 tag on the page, and you're done.
Re: Let's make the worst Htmx
#7The Github link at the bottom contains a `,` char, might want to fix it.
Re: Let's make the worst Htmx
#8[flagged]
Can you please not post AI-generated or AI-edited comments to HN? It's not allowed here - see https://news.ycombinator.com/newsguidelines.html#generated and https://news.ycombinator.com/item?id=47340079.
Of course, it's impossible to know for sure what was LLM processed or not, but some of your posts (like this one) have been getting classified that way.
Re: Let's make the worst Htmx
#9We already have the naughtiest htmx
Re: Let's make the worst Htmx
#10Huh, 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?
the network is faster than so much shitty client-side JS these days.