"Why should only <a> and <form> be able to make HTTP requests?"
Because of accessibility tools, especially screen readers.
This looks like yet another DSL that has to be learned, and does not appear to do anything to solve the UX issues of Web 1.0 that jQuery didn't. (I recall plenty of attempts to build frameworks on jQuery that relied on automagically parsing commands out of data-x attributes).
Additionally, you now need to know your server language's DSL, whereas the bigger tools all offer server side rendering via JS if that is your thing.
I am not saying it is bad, only that I don't think it is an answer for this thread.
Since htmx tries to fold in alongside the regular HTML concepts (which you need to know anyway) you need to know less, and your back end can be in whatever language you prefer. No javascript on the front end, no pressure to adopt it on the back end.
Accessibility is a concern, but, like everything else, has to be traded off against other concerns.
No, it really doesn't. It is mandated by law for at least some categories of websites, and opting to ignore it entirely (as the demo of HTMX apparently does) is extremely user hostile.
> All interactions are via HTML
HTMX is still javascript. Turn JS off, and you end up with a button that does nothing.
AJAX is also a DOM and JavaScript concept, not an HTML one. You need to account for error and loading states, or your users will have a bad time. That means embedding content in the document that isn't actually relevant to the state of the document.
It sounds more like a leaky abstraction that tries to pretend REST/HATEOAS is an HTML concept, when it is orthogonal... About as accurate to say that it is an XML or JSON concept.
The active search demo:
https://htmx.org/examples/active-search/
is another example that can degrade gracefully in the absence of javascript: wrap the input in a form and do the normal post-back for non-JS enabled clients.
With respect to REST & HATEOAS, note the first term in HATEOAS: Hypermedia as the Engine of Application State. HTML is the hypermedia that Fielding was describing in his dissertation. (XML and JSON are not hypermedias, so I'm not sure what you are getting at with that as a comparisong)
htmx tries to use HTML (a hypermedia) as the data interchange, thereby respecting the uniform interface of the original web model. No side state, no interpretation, no special knowledge: just exchanging hypermedia with a server. This is in keeping with the network model Fielding was describing in a way that a React client, for example, is not.
htmx tries to extend and complete HTML along the lines it was already going, before it stalled. Yes, it uses the tools available to do so, which are javascript, unfortunately.
The fact remains client side JS frameworks did not grow organically from the open source community. They had to be pushed into the dev mindspace by the mega-caps tech cos to offload processing power to the client. For the vast majority of companies (all but a handful), front end frameworks hold an org back.
I’ve had this unpopular opinion for several years, and have yet to meet/work with a startup who didn’t regret choosing Angular/React/etc.
Then there's the problem that the page could have changed since the user started filling out that form, what happens when those form values now conflict etc etc
The difference between serving a dead fish of a HTML page, and a SPA application is vast because you're essentially creating 2 independent systems, server and client instead of just server and then adding one of the hardest thing in computing which is consensus between disparate systems
I'm quite excited about React Server Components because it means for the majority of your web app you can return to the simplicity of shipping HTML it doesn't solve everything but at the moment client side applications have a lot of boilerplate to do with just keeping the server in sync that would have been historically "for free" in a server context
I'm loving it that the trend is starting to go back to rendering HTML from the server, then sprinkling on dynamic elements when desired. It's so much more efficient whether you're talking compute, developer time, or the ability to stay agile and change/add features as you learn about the market.
The idea that client side JS was pushed to offload processing power is a bit ridiculous. Do you have any evidence for that claim? Many React sites these days do SSR anyway (running the client-side code on the server) so it doesn't seem like they would save money doing that.
No.
The traditional approach was web 1.0, which was abandoned due to UX issues, not complexity.
Later on, the chaos of direct DOM manipulation by multiple javascript entry points became too much and was formalized into the SPA frameworks we see today.
An alternative solution is to go back to the true traditional approach & address the interactivity issues within that architecture (REST/HATEOAS).