←back to thread

Less Htmx Is More

(unplannedobsolescence.com)
169 points fanf2 | 1 comments | 08 Apr 25 08:42 UTC | HN request time: 0.001s | 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. _heimdall ◴[08 Apr 25 13:38 UTC] No.43621641[source]▶
I reach for HTMX when (a) its a project where I have the power to make that decision and (b) I need to render state that lives on the server.

My main issue with SPAs, and client rendering in general, has always been the attempt to client render state that is persisted elsewhere.

There are certain pieces of state that really do live on the client, and for that client rendering is great. A vast majority of cases involve state that is persisted somewhere on the server though, and in those cases its needlessly complex to ship both the state and an entire rendering engine to the browser.