←back to thread

Less Htmx Is More

(unplannedobsolescence.com)
169 points fanf2 | 2 comments | 08 Apr 25 08:42 UTC | HN request time: 0s | source
Show context
throw10920 ◴[08 Apr 25 11:18 UTC] 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 #
1. stevoski ◴[08 Apr 25 12:51 UTC] No.43621160[source]▶
> "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"

That's an assertion I don't agree with.

Data still needs to come from or go to the server, whether you do it in a snippet of HTML or with an API call.

In either case, latency is there.

replies(1): >>43627657 #
2. throw10920 ◴[09 Apr 25 00:02 UTC] No.43627657[source]▶
> That's an assertion I don't agree with.

The part about users being more latency-limited than compute-limited, or wanting to push as much to the browser as possible?

The former is somewhat hard to quantify, but most engineers building interactive applications (or distributed systems, of which interactive client-server webapps are a special case) have far more trouble with latency than compute.

The latter is definitely true.

> Data still needs to come from or go to the server, whether you do it in a snippet of HTML or with an API call. ... In either case, latency is there.

This is definitely incorrect.

Consider the very common case of fetching some data from the server and then filtering it. In many, many cases, the filtering can be done client-side. If you do that with an interactive frontend, then it's nearly instant, and there's no additional fetch to the server. If you shell out to the server, then you pay the latency penalty, and incur a fetch.

"In either case, latency is there." is just factually wrong.