I really dislike the discourse around htmx. I think the closest words I can use to describe it is glib, insincere and reductive (and yes I get that it's supposed to be meme:y).
It pretends to not be a JS library/framework while it is. It tilts at windmills that are badly structured/built apps.
I agree that most webapps are built on too large libraries. I agree that the dependency chains are crazy. etc. etc.
But the solution proposed by htmx is IMO bad and the self-righteous tone is even worse.
I enjoy the somewhat irreverent takes. They seem appropriate when directed at the often entirely inappropriate use of some modern frontend frameworks.
I've worked with some newish developers that know of no other way than to bring in a frontend framework for the simplest of things. E.g. adding a carousel (don't ask) to an existing site that has no need for a build step and the first thing they want to do is bring in node and react.
I always see these takes and I find them completely at odds with my experience. I have rarely seen a non-trivial frontend project that wouldn't benefit from a build step.
Going without a buildstep meant remembering the last 2-5 versions of JS and then having to write in the lowest common subset for your browser compatibility requirements. Speaking for myself: being able to keep up with the language evolution and transpile to that compatible subset automatically saved way more pain than configuring a build step cost me.
I don't think it's unreasonable to only want to have to write and read a single dialect of JS across projects. Nevermind all the polyfilling we had to do to get common compatible APIs.
Nowadays, the most recent crop of browser versions are a lot more similar to each other than they used to be.
Maybe your colleagues don't know the DOM APIs or are less comfortable with finding some random jQuery plugin to do a carousel but I can't really begrudge anyone for wanting to have the full capabilities of a modern frontend stack.
Neither does htmx. They have said repeatedly that htmx is just an implementation, those can come and go. What's important is the concept of hypermedia and the way it enables designing web applications.
i understand people who dislike the htmx meme-driven vibe and there are certainly times when i go over the line (i'm a one man shop trying to compete w/ libraries from Facebook/Vercel & Google) but i try to be balanced about when hypermedia is and when it is not a good approach:
I don't mind memes, I often like them. One part I dislike is that you seem to say you are apart from js libraries/frameworks when you are a part of them.
Seems to me like htmx tries really hard to market as "just hypermedia" and it's not. Besides things like 'hx-ws' or 'hx-on' we've already talked about the normal cases where you need custom scripting like normal error-handling.
Just hypermedia (as both the UI and API) has been around for 3+ decades. htmx isn't that and should not claim to be that.
> you seem to say you are apart from js libraries/frameworks
Besides memes I don't see this at all. The htmx project doesn't shy away from what it is: javascript.
Hypermedia has stagnated for 2+ decades. Asserting that hypermedia cannot be more than what current implementations have delivered is stolid and myopic.
htmx represents a vision of: 1. What is the core idea of hypermedia? 2. What would hypermedia look like if the core idea was logically extended to be more useful than the original implementations? and 3. How can you use javascript to fill the gap between the html+http that we have, and this expanded idea of what hypermedia could be?
Obviously it has to do this as a javascript library because that's the only possible path. And it's great that existing web technologies are flexible enough to explore interesting ideas like this. But it's silly to discount a project because it's based on a particular vision of how to add life back to older technology.
htmx is hypermedia oriented in that, when it makes network exchanges, those are in terms of hypermedia, which differentiates it from most js libraries. Not all, there is unpoly, Hotwire, etc as well.
Sse and web sockets are extensions. Hx-on is to address the fact that standard on* attributes can only handle fixed events, but I agree it is wandering away from the core hypermedia functionality of htmx. I was on the fence on adding it, but relented when we found a good mechanism for supporting it (xpath) and some long time users expressed that they wanted to avoid needing something like alpine for the simple scripting use cases of their apps.
Htmx also fires a lot of events and I don’t make a secret of the fact that scripting is part of fieldings description of the web and perfectly acceptable in a hypermedia driven application:
It pretends to not be a JS library/framework while it is. It tilts at windmills that are badly structured/built apps.
I agree that most webapps are built on too large libraries. I agree that the dependency chains are crazy. etc. etc.
But the solution proposed by htmx is IMO bad and the self-righteous tone is even worse.