It is exactly dismissing the possibilities some tools are better than others for particular jobs, and it has been a popular phrase for people advocating for bad tools for decades.

The previous favorite one used to be "a bad craftsman blames his tools", that people that liked to impose bad tools on others repeated all the time. But that phrase got old.

> it seems to be dismissing the possibility that some tools are better than other tools for a particular job

I think these are 2 dimensions. Great engineer + right tool is obviously the best combination. Great engineer + wrong tool can work surprisingly well. I have never seen the other 2 combinations produce elegant results.

But really what I was trying to say is this: We're just smearing complexity around. UI is hard. The component model won for a reason. Use whatever syntax you prefer, they're all fine, but please use composable components of some sort to build your UI.

Htmx doesn't preclude a component model for the UI. See:

- https://www.fastht.ml/

- https://github.com/yawaramin/dream-html/tree/todoapp/app

In fact if you look at how htmx is recommended to be used, you realize they specifically are recommending a component-based architecture: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-i...

That is the point I was making: HTMX is just a flavor of the component model.

Eh, not really. Htmx is a tool that you can plug in to your system. It doesn't dictate what system or architecture you use. You can have a component model, or you can have old-fashioned string-based HTML templates. Htmx is agnostic to that.