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.
> 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.
In your analogy, the client JS code is like the serverside code, fetching over the network instead of directly from the DB, and then doing essentially the same work from there... materializing html and a set of controls for the user to interact with.
In a sense, I see your point.
But there's a difference: When you materialize the html on the server and send that over the wire, the browser does all the work for you. When you take the SPA approach, you must re-implement much of what the browser does in JS, and hence the well-known trouble with routing, history, and so on. You can argue that React/Angular/whatever takes care of this for you at this point, and to some extent it's true, but you're still cutting against the grain. And even as mature as the frameworks are, you will hit weird edge cases sometimes that you'd never have to worry about with the browser itself.
There's some difference, but I'm still not convinced. An htmx app is still using JS to manipulate the state of the DOM based on the results of API calls. You could build an app with web-components that do the same local modifications using JSON payloads.
There are definitely advantages to using a multi-page application architecture, which htmx is going to get by default.
But I really don't see a big difference between using JS to replace DOM fragments with server generated HTML, compared to using JS to replace DOM fragments with client generated HTML.
You touch on something that bugs me about these discussions: Lack of proof. Show me the web app with killer UX developed with htmx. Show me the product of the tools and processes being advocated.
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.