I came to similar conclusions as you at some point (minus your first point, which is more of an organizational or tooling/tech issue and not very interesting to

I came to similar conclusions as you at some point (minus your first point, which is more of an organizational or tooling/tech issue and not very interesting to me [0]): HTMX is great if you need "static website with forms and stuff"++ levels of interaction. Basically anything that is database heavy CRUD stuff _without_: interactive and rich visualizations, complex document / rich text editing, drag and drop stuff etc. So it has very glaring limitations. But I think it's very, very good within those constraints. It's very light and adds minimal overhead, it's very simple and it leans on _standards_, (HTTP/REST). But there's an opportunity to combine this with another, very light, minimal overhead, simple library/tech that leans on standards. Namely web components. I recently started a new project that we're going to ship as a JS bundle. It's basically just a UI that gets dynamically rendered on some site (that we don't control). So I gave lit/lit-html a go and it's been a breeze. What I'm thinking now is why not use those two things together, solving separate problems? They are like ying and yang. Web components integrate with or can wrap more heavy weight interactive things easily. HTMX gives you a sensible, simple way of talking to the server. [0] To say at least something about it, separating your UI layer is really more about sensible code organization and decoupling. If your tools/framework/libraries make this hard, kick them in the can.