I don't see how that has anything to do with the choice of htmlx. You always have the freedom to use any languages in the backend. If anything, htmlx imposes a bunch of hypermedia convention on top of your conventional API, regardless of languages.

Back-end devs think htmlx will allow them to be comfy in the back-end and just trash their front end with "thin client" that has no framework or any sort of organization. Eventually someone who is willing to actually think about front-end has to rebuild it and decouple the 2. Happens all the time.

I want to be able to be able to code in a more natural back end setting - I like Raku, others may prefer Go (or Rust or PHP or JS). I am not ready to commit to a complex event driven framework like using the WordPress backend and React on the front end. But I do recognise that a pure browser only model for UX is too crummy … let’s say I want to validate an email … well if I specify input email in HTML, my browser will pop and ugly dialog if there is no @ in the input.

So HTMX gives me my backend coding preference and a clean way to add simply tweaks to the UX. That is the power of HTMX for me.

I don’t think HTMX is a good solution is you want to write Google Maps or Facebook. But it is a great way for straightforward sites to be written and I do not understand why I will be forced to step into JS front end rewrites if I go this route (and I can happily bundle some JS + CSS + HTML into an HTMX response for the islets where I need it.

I think the point the OP is making is that very new frontend frameworks dictate what backend language you use. They just use HTTP requests and consume JSON.