OK I reckon everyone is going to get on the HTMX wagon over the course of the next few months, and it's going to blow a ton of young minds and save a huge amount of global energy and make a lot of people very happy. And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come out
This is an infinite cycle with JS though. Someone tired of JS complexity writes a simple JS lib (SJSLib), SJSLib attracts people for simplicity, SJSLib grows complex because it has to support all the web things, someone tired of SJSLib complexity writes a simple JS lib...
I say this as someone who started with raw JS and fought IE5/6 for years, jQuery then saved us all, skipped over AngularJS because it was meh, React beta finally came around and loved it for FP ideals, now wade thru piles of transpiling / hot-reload / Typescript and React fat-libs. Have also written a few projects with both Intercooler (and now HTMX).
HTMX is overall solid, but this ain't the first wagon to come through town.
To this comment’s replies: The dev of HTMX has said and is well aware that HTMX/hypermedia-based approaches don’t work well for every type of web app, but claims that it fits well with the vast majority of them, so the chance of it becoming bloated for want of fitting every single use case is pretty low. Greg says that a developer’s most valuable weapon against the complexity demon is limiting features by saying “no”, so I think the chance is pretty minimal.
So the cycle spoken of would be broken at this sentence. “SJSLib grows complex because it has to support all the web things.”
Ah! Carson Gross is author of grug brained developer, and htmx!
I'd love to see some real critiques of htmx.
Personally I think the web's big ongoing challenge has been figuring out how to update the page well, and we keep trying all kinds of attempts. That causes fatigue, and some of the ideas are wild or grow crufty over time. Htmx seems like a back-reaction, to insist on grug brained less/YAGNI.
And even though the future is uncertain, I still see work on things like signals as saintly. There's a lot of different pokers in the fire, refining & trying different angles. We're still pioneering this front, other fronts.
The quest feels similar to so many others. MobX and Svelte and others have made great journeys already. That the journey is still irresolute, that we do keep tangling with the complexity beast: rather than that being a sign of weakness, as the conservative/grug minded might take it for, I think and I hope it's appropriate & due effort to reach a simple but good. Rather than a just simply simple approach.
Why would I write my own JS when "hx-get" does the job? Writing your own JS makes sense in some cases, but using HTML partials is also useful in many cases where you need to talk to the server anyways (since they e.g. prevent logic duplication). HTMX just makes it easy to work with them, as they're a single attribute away, rather than doing the request and insertion by hand.
Native clients are deliberately out of scope, but scraping HTML isn't the suggested solution. Rather, it is having a JSON API next to the hypermedia API: https://htmx.org/essays/splitting-your-apis/. This does have the downside of duplicate work, but does bring stability to the API without introducing something like GraphQL.
And yes, you will need to learn HTMX to use HTMX. But the surface of HTMX is generally quite small, and composes well with knowledge about HTML/CSS.
The best critique of HTMX is the same critique of Rails + partials + a bit of helper JS for inserts (the popular stack that predates modern SPAs.)
Say you’re writing a true web app. You’re making a mobile view, and the user has scrolled down and loaded some items (and partially inserted them as the scroll bar has moved down.) They add a card representing a few items to a cart, which 1. changes the look of the card and 2. the number that floats above the cart icon in the header.
Do you
1. Return the updated card and insert it as normal, then pass the HTML to figure out the number to change the cart icon with and call JS to change that icon?
2. Trigger a full page reload, meaning that both items update at the cost of losing the scroll position?
3. Break convention with HTMX and call a JSON API that will let you return the updates primitive values, and maintain the display logic changes in JS?
4. Have a weird hybrid JSON + HTML API that return multiple responses for each part of the DOM tree that needs changing and rely on some custom JS to do both updates?
> And then these same inquisitive young people are going to click enough links on htmx.org that they stumble across hyperscript and it's gonna be like that moment in Dusk till Dawn where the vampires come out
I laughed at this, then I checked.
_="on load wait 5s then transition opacity to 0 then remove me"
Oh no!
_="on htmx:error(errorInfo) fetch /errors {method:'POST', body:{errorInfo:errorInfo} as JSON} "
If it's in the trailer it's fair game. Besides an actual spoilery description for From Dusk til Dawn would be all the non-vampire parts. The "twist" is that a movie billed as Robert Rodriguez vampire schlock actually has an entire other movie contained in it. That's a bit of a spoiler I suppose, my bad.
