Htmx Is the Future

> Hugely increased complexity both in terms of architecture and developer experience. You have to spend considerable time learning about frameworks.

You have to learn something. You can claim bloat in JS frameworks, but that isn’t solved by simply moving it to the server.

Is htmx lean and nice today? Probably! But does it handle the same use cases that the React users have? What happens to it under pressure of feature bloat? Small-core frameworks like Elm who resisted this pressure were abandoned by big shops. You can’t just take something immature (however good) and simply extrapolate a happy future.

> Tooling is an ever-shifting landscape in terms of building and packaging code.

Yes. JS is not the only language with churn issues and dependency hell.

> Managing state on both the client and server

Correct me if I’m wrong, but state can change for something outside of a htmx request, meaning you can end up with stale state in element Y in the client after refreshing element X. The difference is that your local cache is in the DOM tree instead of a JS object.

> By their nature, a fat client requires the client to execute a lot of JavaScript. If you have modern hardware, this is fine, but these applications will be unusable & slow for those on older hardware or in locations with slow and unreliable internet connections.

On unreliable connections you want as thick of a client as possible. If you have server-in-the-loop for UI updates, you quite obviously have latency/retry issues. It’s much preferable to show stale state immediately and update in the background.

> It is very easy to make an SPA incorrectly, where you need to use the right approach with hooks to avoid ending up with abysmal client-side performance.

Bloat comes from reckless software development practices, and are possible in any technology. Angular and React have a shitton of features and ecosystem around it, whereas say Svelte is more lean. Enterprisey shops tend to prioritize features and not give a flying fuck about performance. This is a business choice, not a statement about technology.

> Some SPA implementations of SPA throw away progressive enhancement (a notable and noble exception is Remix). Therefore, you must have JavaScript turned on for most SPAs.

Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM?

I love that htmx exists. I have absolutely nothing against it. It honors some of the early web philosophy in an elegant and simple manner. It may be a better model for server-centric apps and pages, which don’t need offline or snappy UIs. But it cannot magically solve the inherent complexities of many modern web apps.

I'd rather see either:

* NextJS provide a holistic solution to backend code. Right now it's missing an ORM that works with serverless postgres. Given their recent additions of serverless postgres to Vercel I expect this will happen in 6-12 months.

* RedwoodJS become more mature.

The issues with SPAs IMO come from having to cobble together your full stack app, which requires making a ton of hard decisions in predicting the future of each major library you use. And then there's limited coherence between your ORM, API, and client without extra work. A mature, well designed, and financially supported full stack JS solution that truly rivals Rails would be perfect.

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way.

But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular.

Some of the specifics in the comparisons are always weird, too.

> Instead of one universal client, scores of developers create bespoke clients, which have to understand the raw data they fetch from web servers and then render controls according to the data.

This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data.

You're still coupled to the data, and your htmx endpoint is just as "bespoke" as the client code which uses it. It's not wrong to prefer that work be done on the server instead of the client, or vice versa, but we're really just shuffling complexity around.

That's really nice!

   > Finally, we cut to the chase. This is 100% true, and we should be talking about this, because it’s still not settled: do we want web pages or web apps? If both, where is the line? Can you expect something like Slack to work without JavaScript? What about a blog with interactive graphs? Should everything degrade or should some things require JS/WASM?

BINGO. At times, it seems everyone is talking through each other because we are thinking of different things: static pages, dynamic websites, web apps, etc. all require different approaches to development. Honestly, what gets me real mad is when you need to run JavaScript to see a static page, I just can't stand it, one lovely example is the blog post we are talking about which displays awful without running JavaScript, this proves that indeed HTMX is not a panacea, and you can also "hold it wrong" (the blog post in question uses HTMX in the backend).

Overall, I believe most applications do well with a graceful degradation approach similar to what Remix offers and then everyone copied (the idea of using form actions webforms-style for every interactivity, so it works with and without JavaScript). I do agree that things like Slack, Discord, Element, or otherwise things we would call web apps are acceptable to be purely SPAs or not gracefully degrade without it enabled, the biggest problem I have with these is that they exist as web clients in the first place: the world would be a different place if approaches such as wxWidgets has paid off and gotten adopted, imagine how many slow and bloated web apps could've been beautiful and fast native applications. One can dream. I'm not that pessimistic, not yet.