HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX.
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node).
Certainly agree that HTMX is not for everything. Nor is Raku ;-)
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?