Look at each of the distinct things that htmx lets you do, and tell me what would be required to do it in vanilla JavaScript. Notwithstanding that even in your example `onload = function() { e.innerHTML = response.body` } [sic{ doesn’t even tell the whole story, HTMX does more than just this and this is blindingly obvious from its documentation. If you need those things more than, say, a couple of times in your project, the natural thing to do is to factor them out to what essentially becomes a framework. This is what that is. HTML element attributes is used as the interface because there are a whole lot of people that don’t like switching to writing JavaScript. You can argue all you like that you’re not a fan of this, but plenty of people are. You can also argue all you like that one will eventually need to write some JS which will make the whole thing confusing to follow. The reality is that there are a whole load of projects where this isn’t the case. If you’ve spent this long going back and forth with people about the merits of this project, and still don’t see it’s value, then it legitimately isn’t addressing a problem you have, or, more likely, it isn’t to your personal style/taste, or for whatever reason you are unable to relate it to any personal circumstances you’ve ever been in. The documentation gives tonnes of practical examples of how the framework can be useful, and there’s mountains of third party examples. Beyond that, your arguments seem to revolve around a lot of technical, performance, and DX hypotheticals that you could test yourself by experimenting with the project. Part of its selling point after all is the lack of a need for complex build tooling. If you still legitimately can’t see the value then it doesn’t seem worth the discussion.

In practice you don't want to just swap the content 100% of the time. Appending to the current content is quite common too, as is deleting from it. You sometimes need to touch other elements too, or maybe show a progress spinner. Or perhaps push a URL to the navigation history.

Htmx provides a batteries-included data-driven experience. It is a means to avoid having to write dozens of slightly different variants of the same 5-10 lines of Javascript.

But all of those things are trivial. Are we going to next get a library that lets you declaratively specify string operations and integer multiplication? Why not write a dozen variants of 5-10 lines of readable Javascript? What's the problem? It's maintainable, fast and every other developer will immediately understand it.

One of the stated goals is to make html a true hypermedia language right? That's really pretty much it.

A lot of these objections sound like "why bring these functions into JavaScript if JQuery already exists? Why do we need CSS Grid if bootstrap already exists?" Because those are arguably add-ons meant to deal with the deficiencies of the original technology. Fixing that technology is a better place to be.

Except that it doesn’t fix the technology, it gives the appearance of augmentation via a bunch of JavaScript. Seems more like the jQuery and Bootstrap of your examples.

Sure, you don’t have to look at it, you just program against the interface. Just like you don’t have to look at the internals of jQuery - you just program against its interface.

Please see my answer above, but htmx has some swap attributes where you can declaratively update as many elements of the page as you want. You can grep this id and find all the updates easily.