HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.
In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get to target a section of the page that isn't an has been argued about and hashed out for years.
Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. https://github.com/whatwg/html/issues/new?assignees=&labels=...
It asks three main questions:
* What problem are you trying to solve?
* What solutions exist today?
* How would you solve it?
The goal of these questions is to focus primarily on the problem, and only secondarily on the solution.
For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding and elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually.
So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better?
HTMX doesn't have really great answers to the "what problem?" question. Look at the home page:
* Why should only and be able to make HTTP requests?
* Why should only click & submit events trigger them?
* Why should only GET & POST methods be available?
* Why should you only be able to replace the entire screen?
Those questions are all solution-oriented, not problem-oriented.
Instead, let's look at the examples. https://htmx.org/examples/
Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility.
For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.)
Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates.
Some of the HTMX examples already have recent new HTML features that support them directly, like , declarative form validation, using as an accordion (which you can use to support tabs).
In the future, I expect to see HTML features landing like these:
* Editable data tables
* Infinite scroll / lazy loading
* Combobox
* Skeleton UI / Loading
If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding or elements, the problems it solves seem to all have better solutions at a different level.
And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution.
But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)