Let me understand... Client-side JS is bad because etc. etc. Use this solution. It's implemented as a client-side JS library. Duh!
So it's not a game changer, just a less-bloated JS solution?
HN loves this library but I really don’t get the appeal. It extends HTML with a bunch of attributes with their own syntax:
hx-trigger="keyup changed delay:500ms"
hx-trigger="click[ctrlKey]"
It fires off weird events you’re supposed to hook into with JS:
document.body.addEventListener('htmx:beforeSwap', function(evt) { …
You lose static analysis and gain hard to track down bugs merely from typos
It reminds me of ColdFusion and Angular v1, with its extensions to HTML. HTML was meant for defining content structure, not behavior
Just use plain JS over this if you hate React so much. Or jQuery even. Keep the behavior out of the content layer.
The server returns the HTML ready to display directly. End of story.
What server doing ? it uses cgi, python, etc myriad of scripts to generate html
Whats better, a button click and js in browser opens a menu, or fetching a new html with menu open
I've been working with React Server Components recently. A lot of the points here are applicable for RSCs too. The problem IMO, is Next.JS. Most apps don't need edge computing or fancy caching (which Vercel sells). Take those out, and I think we'll have a nice framework that's easy to use for everyone.
HTMX is cool but no bueno for offline clients.
The overuse of emoji make me suspect it's AI. I plugged first paragraph into pangram and result is 100% AI.
https://www.pangram.com/history/30310094-f54b-4e74-8d68-e4c9...