←back to thread

Less Htmx Is More

(unplannedobsolescence.com)
169 points fanf2 | 1 comments | | HN request time: 0s | 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 #
1. tannhaeuser ◴[] No.43620674[source]
Yeah I don't get the irrationality either, especially the dogmatic "hypertext" angle. I mean you can see me pontificating about SGML as the original complement to the HTML vocabulary bringing text macros and other authoring affordances, but that is strictly for documents and their authors. If you want to target web apps and require JS anyway, I don't see the necessity for markup and template languages; you have already a much more powerful programming language in the mix. Any ad-hoc and inessential combination of markup templating and JS is going to be redesigned by the next generation of web devs anyway because of the domain's cyclic nature ie. the desire to carve out know-how niches, low retention rate in webdev staff, many from-scratch relaunches, ..,