Hacker News Reader

Comment by wren6991 | Hacker News Reader

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?

View on HN

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.

Supply chain attacks are not a JavaScript or npm exclusive risk. If you pull in any dependencies you have a supply chain risk.

As is well known, security is not a binary, it's a spectrum. It's why you add security in layers, and why it's generally a trade-off between risk and usability.

Your mileage may vary, but I sleep better with my own projects not having any node_modules in their build tree.

How is htmx invulnerable to vulnerabilities and attacks?

It's not invulnerable, I think gp just means that reducing your amount of dependencies reduces the attack surface.

Who is worrying? If JavaScript is on the front end the supply chain attacks are really not your problem.

The supply chain attacks you need to worry about come from using npm.

No, it's not specifically npm. All package managers enable remote code execution by design - you tell it to download code and then you run that code, likely without sandboxing, by using it. Most people are not inspecting the code before they download and run it. You will still see compromised packages making their way through npm even though they disabled install scripts.

I agree. I just pointed out npm because it's the most prominent javascript one.

What? It handles your password fields.

Just do SSO.

Just do passkeys.

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 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.

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.

the network is faster than so much shitty client-side JS these days.

When you say these days, I’d argue since mid/late 2000’s for internet with a cable vs. radio waves.

Radio waves caught up in developed countries with 4G roll outs in my opinion(is that mid 2010’s?).

Large client side JS has been garbage for most things since it’s inception.

Datastar has a lean and mean signals implementation that handles all the front-end reactive stuff - so you don’t have to go to the server for interactivity.

The problem with HTMX is not network traffic but needing to use hyperscript for anything advanced.

Also don't you entirely lose typing?

My favourite thing about TSX is that it is typechecked. How do you do that with random strings of HTML?

I still write tsx and my components look very similar to react -- just no hooks. The difference is I render to html server side and send the rendered html. Look into it in hono

Reply on news.ycombinator.com