10 sats \ 1 reply \ @halleck 7 Jun \ on: HTMX Intrigue devs
I'm in a similar boat. I am intrigued by htmx as a solution for simple web tools I maintain for work. I've done some simple proof of concept apps, but haven't taken the dive into actual production track code.
Yeah, same here. Using it on my own site was just a proof of concept.
Currently, I see HTMX as a way to progressively enhance a website. By default, the server serves static HTML which should be really fast with something like nginx. If Javascript is enabled, HTMX tags will be used to make it more dynamic, at the cost of additional roundtrips vs SSR.1
I like this approach from keeping it as simple as possible and then gradually enhancing it. I also started to like constraints since they make me creative, especially when these constraints force me to keep it simple. Just serve HTML, no (immediate) need for hydration, client-side routing, state management on the client, serving a ton of Javascript etc. like is usual for SPAs built with frameworks like React.2
I've also read about using a serviceworker for HTMX that can intercept requests so you could serve HTML fragments even offline (assuming you can predict what the server would respond with). The biggest downside of HTMX seems to be that by default, it does a network request for everything but it at least eliminates full page reloads since it handles fragments.
So if you ever want client-side routing with HTMX, a serviceworker could be the way.
Footnotes
-
I should use
<noscript>to gracefully degrade the comment link to a comment link with no data about how many comments exist. Or maybe I don't even have to use<noscript>, I can simply replace the existing fragment in the initial server response? 🤔 ↩ -
The dark web is actually a great inspiration for this stuff. Markets in there work pretty decently (almost like SPAs) with no Javascript enabled. ↩
reply