I love seeing more work in this space! This sounds similar to the approach Basecamp has taken, with tools like stimulus.js (combined with with Rails UJS and Turbolinks). You can make a really responsive page with normal server-side HTML templates that "sprinkle" in the ajax functionality.
Tools like this feel very familiar to those of us who got started before the rise of the modern JS framework. It's kind of fun to see articles like the OP's pop up where people are rediscovering these techniques.
The problem is that HTML was never completed as a hypertext, they just kinda stopped at anchor tags and forms.
There isn't a good reason that only anchors and forms should be able to specify HTTP requests. There isn't a good reason that only clicks or form submits should be able to trigger HTTP requests. There isn't a good reason that only POST and GET should be readily available (and POST only for forms.) And there isn't a good reason you should have to replace the whole page on every HTTP request, rather than a component within it.
htmx is an attempt to complete HTML as a hypertext.
There isn't a good reason that only anchors and forms
should be able to specify HTTP requests. There isn't a
good reason that only clicks or form submits should be
able to trigger HTTP requests. There isn't a good reason
that only POST and GET should be readily available (and
POST only for forms.)
That's an excellent and thought-provoking way to think about it.
I'd always been mentally locked into HTML's basic "the web is a series of linked pages" paradigm that was in effect ever since it debuted, thinking that to do anything outside of that paradigm you'd obviously want to resort to manipulating the DOM directly with javascript.
But, there's really no reason for responsibilities to be divided in quite that manner. There's really no reason HTML itself can't encompass somewhat more robust hypertext features, with declarative support for functionality like "this link should load URI abc in the xyz region of the current page."
Frames, of course, did sort of do that natively in HTML, but that was a very clunky implementation to put it mildly.
I can think of potential arguments against what you say, but I think I agree...
Right. And not only is there no reason for responsibilities to be divided that way, as it stands you kneecap the promise of REST/HATEOAS by restricting it to the very specific cases of anchors and forms.
So with htmx I'm trying to complete the HTML hypertext and let people take advantage of the simplicity of the REST model without sacrificing user experience.
Once I got past certain mental blocks, it became fairly obvious that you can structure all your GUI scripts to be configured and to interact with one another via DOM.
The next insight was to use CSS selectors for targeting.
Then using consistent name prefixes and separating behaviors into self-contained libraries.
The stuff above was proof-of-concept. The possibilities behind this approach are mostly unexplored.
Tools like this feel very familiar to those of us who got started before the rise of the modern JS framework. It's kind of fun to see articles like the OP's pop up where people are rediscovering these techniques.