←back to thread

Less Htmx Is More

(unplannedobsolescence.com)
169 points fanf2 | 1 comments | | HN request time: 0.001s | source
Show context
throw10920 ◴[] No.43620387[source]
While I get the emotional appeal, I still don't understand the use-case for htmx. If you're making a completely static page, you just use HTML. If you're making a dynamic page, then you want to push as much logic to the client as possible because far more users are latency-limited than compute-limited (compare [1] vs [2]), so you use normal frontend technologies. Mixing htmx and traditional frontend tech seems like it'd result in extra unnecessary complexity. What's the target audience?

Edit: "Normal/traditional frontend" here means both vanilla (HTML+JS+CSS) and the most popular frameworks (React, Angular, Vue, Next).

[1] https://danluu.com/slow-device/

[2] https://danluu.com/web-bloat/

replies(9): >>43620401 #>>43620449 #>>43620467 #>>43620547 #>>43620624 #>>43620674 #>>43621160 #>>43621499 #>>43621641 #
cies ◴[] No.43620449[source]
I agree with the author of the article in that it's often best to do as much as possible in plain-old HTML.

When an interactive "widget" is needed, I try to simply embed that in one HTML page, and avoid to make the whole app an single page application (SPA).

SPAs are problematic because you need to manage state twice: in the BE and FE. You also may want a spec'ed API (with client library generation would be AWESOME: GraphQL and OpenAPIv3 have that and it helps a lot).

> so you use normal frontend technologies

This is the problem. "Normal" means React/Vue/Angular these days and they are all shit IMHO. This is partly because JS is a rampification and TS fix only what could be fixed by _adding_ to the language (since it's a superset). So TS is not a fix.

I had great success with Elm on the frontend. It's not normal by any norm. Probably less popular than HTMX. But it helps to build really solid web apps and all devs that use it become FP-superstars in a month.

Tools like ReasonML/ReScript and PureScript may also have these benefits.

replies(1): >>43620507 #
throw10920 ◴[] No.43620507[source]
> SPAs are problematic because you need to manage state twice: in the BE and FE. You also may want a spec'ed API (with client library generation would be AWESOME: GraphQL and OpenAPIv3 have that and it helps a lot).

OK, this helps explain some of the reasoning.

Unfortunately, that means that the tradeoff is that you're optimizing for user experience instead of developer experience - htmx is much easier for the developer, but worse for the user because of higher latency for all actions. I don't see how you can get around this if your paradigm is you do all of your computation on the server - and 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.

> "Normal" means React/Vue/Angular these days

I didn't mean (just) that. I included vanilla webtech in my definition of "normal" - I guess I should have clarified in my initial comment (I just meant to exclude really exotic, if useful, things like Elm). Does that change how you would respond to it?

replies(4): >>43620807 #>>43621105 #>>43621124 #>>43621954 #
intrasight ◴[] No.43620807{3}[source]
>higher latency for all actions

If your implementation is poor

> all of your computation on the server

You doing weather forecasting? Crypto mining? What "computation" is happening on the client? The only real computation in most web sites is the algorithmic ad presentation - and that's not done on your servers.

replies(1): >>43620902 #
throw10920 ◴[] No.43620902{4}[source]
> If your implementation is poor

This is factually incorrect. Latency is limited by the speed of light and the user's internet connection. If you read one of the links that I'd posted, you'd also know that a lot of users have very bad internet connection.

> You doing weather forecasting? Crypto mining? What "computation" is happening on the client?

This is absolutely ridiculous. It's very easy to see that you might want a simple SPA that allows you to browse a somewhat-interactive site (like your bank's site) without having to make a lot of round-trips to the server, and there's also thousands of examples of complex web applications that exist in the real world that serve as trivial examples of computation that might happen on the client.

> The only real computation in most web sites is the algorithmic ad presentation - and that's not done on your servers.

I never mentioned anything about "ads" or "most web sites" - I was asking an engineering question. Ads are entirely irrelevant here. I doubt you even have data to back this claim up.

Please don't leave low-effort and low-quality responses like this - it wastes peoples' time and degrades the quality of HN.

replies(2): >>43621490 #>>43622357 #
1. skydhash ◴[] No.43621490{5}[source]
If you want to help people with latency issues, the best way is to sent everything in with as few request as possible, especially if you don’t have a lot of images. And updating with html (swapping part of the DOM) is efficient compared to updating with JSON.