Comment by wg0
23 days ago
This evangelism around HTMX is bit misplaced.
First - simple use cases sure great. But imagine you have to update some element out of the from tree. Now you need to have OOB swaps and your HTML must contain that fragment.
Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
Even at decent size app, soon it turns super brittle.
Yet to talk about complicated interfaces. Let's not go complicated just think of variants in an E-commerce admin panel.
3 variants with 5 values each these are 125 SKU rows that must be collapsed group wise.
htmx can do it but it's going to be very very difficult and brittle.
So it is surely very useful but it is NOT the only tool for all use cases.
> Now you need to have OOB swaps and your HTML must contain that fragment.
This is super simple to do if you are using a library to generate HTML in your backend programming language.
> Not just that your server template code now has to determine if it is HTMX request and only render OOB fragments if so.
This is literally just a function that checks for a couple of headers, chooses between two rendering options, and adds a `Vary` response header to take care of the caching. Hardly anything complicated.
> htmx can do it but it's going to be very very difficult and brittle.
The problem with this summary is that it misses the point–htmx is not doing backend stuff, your backend app server is. Htmx is just swapping in what the backend sends.
> it is NOT the only tool for all use cases.
The OP said exactly this, the htmx people have always said this, and no one ever claimed otherwise. There are people out there who don't think in absolute all-or-nothing terms.