> Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.
HTMX is great. We use it as a middle ground for mildly interactive parts of the app. Places where jquery/vanilla would get annoying but going full React isn’t worth it. Admin interfaces in particular are a great fit – lots of CRUD, mildly interactive, very repetitive.
Adding `hx-get` to a button or div is way way quicker than writing all that boilerplate javascript yet again for the hundredth time.
Extra bonus: it encourages you to write small self-contained composable endpoints instead of massive kitchen-sink pages.
> Admin interfaces in particular are a great fit – lots of CRUD, mildly interactive, very repetitive. Adding `hx-get` to a button or div is way way quicker than writing all that boilerplate javascript yet again for the hundredth time.
Yes. Then imagine you have a massive legacy codebase and a control panel of something has a ton of data and buttons and inputs and all kinds of nonsense. Say you have a weight and dimensions of a package of a product... you'd like to make it so you can edit these in-place and when you do, a package volume (and/or volume sum of all packages) gets updated somewhere else on the page (along with some other info... I don't know, an estimate of product delivery cost based on volume, which delivery methods are now un/available etc.)
Like... you already have ways to calculate and show these in your server side logic. With HTMX you reuse these, add a sprinkle of hx-get and add some OOB updates and you're done. You can do the same with ajax, but not nearly as fast as with HTMX and much more annoyingly...
Because with HTML you get static, non-flashing, intstantly rendered without load times. So smart developers actually want less Javascript, because the browser already implements most of what Javascript does, why reinvent the wheel?
Why would I write React components myself when I the Javascript isn't really that complicated?
It is bizarre that ONLY HTMX gets these weird "DONT USE THAT ITS NOT POPULAR ENOUGH" criticisms.
XML, XLST get these criticisms except for the XQuery and XPath components because HTML fanatics need that to make their hybrid HTML/JS garbage apps work.
But really the ultimate goal for any good website engineer should be to offload as much logic and processing to the browser, not rewrite everything in JS just because you can.
> But really the ultimate goal for any good website engineer should be to offload as much logic and processing to the browser, not rewrite everything in JS just because you can
Why? This makes for a horrible user experience. Things like TicketMaster, and in recent years GitHub, slow my machine to a crawl sometimes. I much prefer mostly static content. This is a well-made website: https://www.compuserve.com/
Which isn't JavaScript's failure per se. I wouldn't wat to use a Google Maps like thing, with full page reload each time I scroll or zoom or check details of a place.
The issue is of "plain" websites for bad reasons add dynamic stuff.
Why should I write it myself? Sure, I could do that, but then every time I want to have that sort of functionality on multiple pages I would have to write the JavaScript code multiple times. I could then roll it into a library. Maybe make the library work with custom HTML attributes. And now I've just reinvented HTMX. So I might as well use HTMX instead of reinventing it.
Such a weird question. You could ask that about any library ever.
there's a fair bit of functionality in htmx that isn't trivial: history support, event debouncing, etc. you can certainly write it yourself, but there are advantages to having existing functionality that is well tested and fits together reasonably
