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.