The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications.
It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task!
I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
You're absolutely right, htmx is not built for every UX flow.
But neither is React. And we've been reaching for it by default for everything and that's been a mistake.
So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app.
With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step.
I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.
I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members.
Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for.
In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful.
Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front.
Next is ironically fast if you prerender/static generate AND the client disables JS!
> "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state.
The issue with many SPAs I saw was that state had to be managed BOTH in the browser AND on the server. This resulted in more code, longer time to market, and reduced velocity.
The SPA route can be a requirement (e.g. when a highly interactive UX is warranted), in that case there's no way around it. But when it's simply a bunch of forms in a business app, that's usually not the case: in those cases I'd go with a traditional "multi page app" and/or HTMX.
Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation. But in my experience it’s not a bad one because only very best designers i worked with were deliberate about state so they could use this advantage.
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.
> Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation.
Rather than limitation, I think of it as a constraint. The best engineering takes place under constraints, because when you're unconstrained you have a high chance of repeating mistakes that have known solutions. In this case, you rightly point out that the UX of the browser has certain limitations and making all state URL-addressable is the interface to that UX.
this is the argument that resonates with me ... increasing complexity around event driven frameworks includes more cognitive load to reason about state information in two (or more) places whereas the web of olden times was conceived around stateless clients (plus some cookies)
as I say in the post, HTMX is not for you if you are building a web app that needs this ... but in 90% of cases web sites don't
This isn't unique to HTMX though. You can do the same with any frontend framework. You can argue that HTMX forces this to be the case, but has a lot of trade offs in doing so.
It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.