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.
So the cycle spoken of would be broken at this sentence. “SJSLib grows complex because it has to support all the web things.”
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.
- Writing Vanilla JS ES6+ is not that hard, actually it is pretty fun.
- Toolchain for JS/TS/CSS was bad but is pretty good now. esbuild is simple and great.
- Dodging learning the above two things does not serve the dev.
Others have to do with foundational aspects of the project:
- HTMX is in denial of need to support native clients. IIRC, the official recommendation is that native clients should parse HTML for values.
- HTMX is still just a javascript library dependency with syntax that must be learned by whoever picks up the project.
IMO HTMX's buzz can largely be attributed to anti-frontend or anti modern frontend.
This thread describes this idea: https://twitter.com/DanaWoodman/status/1682075711266496512
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.
i like vanilla es6 too. i've enjoyed using it with htmx, rather than using intercooler or alpine.
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?
If you need to modify the card and something else, probably using hx-swap-oob is the best approach to update the cart icon.
I laughed at this, then I checked.
_="on load wait 5s then transition opacity to 0 then remove me"
_="on htmx:error(errorInfo) fetch /errors {method:'POST', body:{errorInfo:errorInfo} as JSON} "
If someone thinks it's ruined because they found out ahead of time that there are vampires in it... yeah, that's their problem.