HTMX Is So Cool I Rolled My Own (2024)
21 points by FedericoSchonborn
21 points by FedericoSchonborn
Minor nitpick but I’m not keen on the hx-* prefixed HTML attributes where data-* should be used
Htmx supports data- prefix and has for a long time.
Users should not be clicking <div> elements.
For best results use htmx hx-boost on anchor and form tags. They automatically enhance these tags in the correct way, so you avoid clickable divs.
it demonstrates how little JavaScript is actually needed in the browser
This project is going to need minimal maintenance and likely zero security patches for the foreseeable future. Congrats.
Does HTMX beat the hell out of your server though? Since you're rendering everything? Kind of like the old CGI problem we used to have
Almost certainly not -- the CGI problem was more around the cost of spawning lots of short lived processes (fixed by things like FastCGI). I don't mean to pick on you at all, but it's funny to me how this always comes up. Generating HTML is by no means particularly expensive, or at least not more expensive than generating a similar amount of JSON for the alternative approaches.
We call it server side rendering, but it is more like creating the server side raw html. The actual rendering, dom creation is still very much (and always has been) done in the browser.
You are also skipping over a whole decade and a half of web development where this was normal. Even if we include PHP under the CGI umbrella.
You are right that it does ask more from the server. Since it offloads a whole lot to the client. Where I disagree is why that largely has been done. The main reasons I have been able to deduce have been cost savings as a calculated risk as a lot of end users will not be able to tell their browser is doing more. I say calculated risk as in many instances, to this day but certainly in the early days, it also degrades the experience for many people on older or less capable devices.
Anyway, I digress as I am talking about full server side rendering anyway. With HTMX that isn't the case. Rather than have APIs send data in json format and letting the client render that to HTML the server side now sends the same data in HTML snippets. If that is still hammering your server I'd recon that it more has to do with other factors as a REST api wouldn't meaningfully consume more resources.
Without benchmarking I wouldn't commit to an answer but my guess is that it's comparable. In both cases you're spitting out a pile of characters, it's just whether rendering text or rendering JSON is more expensive. In my experience, we tend to serialize a lot more when doing JSON. But I don't have a good way to compare.
There’s no reason to believe there’s a significant perf diff between the two: https://github.com/1cg/html-json-speed-comparison
Probably yes, but we have better ways of handling high traffic sites now compared to cgi (and a lot of web tech from that era, tbh). Modern servers hardly flinch at the old c10k problem for example.
For similar reasons I'm actually using alpine-ajax which is very much like htmx.
alpine-ajax
I really like that one too. If I were starting fresh on my "try to get the things people like about SPAs from SSR" mission, I think that's where I'd probably land, mostly because I use alpine for the client-reactive things I want anyway. But I've got a whole lot of htmx in my repositories already, now, and I'm not unhappy with it.
Does HTMX beat the hell out of your server though? Since you're rendering everything? Kind of like the old CGI problem we used to have