HTMX is the same approach as old-school server-side templating, except you can replace parts of the page with HTML returned from the server, rather than always the whole page.

This allows for some nicely responsive interactions, but introduces complexity.

I'm not the previous poster, but it's a fair question whether the maybe faster responses justify the complexity. In many cases it probably would not.

(Actually, I suspect it's rare; if you know how to make partial page responses fast for HTMX, you know how to make full page responses fast and don't necessarily need HTMX, up until your page just gets too large overall.)

The general problem with HTMX is that, by default, the page state, as a function of the initial page plus the accumulated user's interactions with the page, live only in the user's browser tab. This can seem fine for a while, but opens up some fairly fat edge cases (this article covers some of them). There are ways to handle this, but it's additional complexity and work. Maybe someone has or will create an HTMX-friendly server-side templating framework to take the grunt work out of it, but you still have to wonder if one of the numerous existing full page templating mechanisms might not still be superior, overall.

> HTMX is the same approach as old-school server-side templating, except you can replace parts of the page with HTML returned from the server, rather than always the whole page.

Hasn't jQuery been able to do this since the early 2000s? Even vanilla JS has this functionality for decades too.