This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state.

I don't see how it's any simpler to shift partial presentation duties to the backend. Consider this example:

https://htmx.org/examples/active-search/

The backend is supposed to respond with the rows to fill a table. You have an extremely tight coupling between the two. Something as simple as changing the order of the columns would require three releases:

- A new version of the backend endpoint - A frontend change to consume the new endpoint - A version to delete the old endpoint

I'm not trying to be obtuse, but I fail to see how this makes any sense.

Consider something as simple as an action updating content in multiple places. It happens all the time: changing your name and also updating the "Hello $name" in the header, cancelling an order that updates the order list but also the order count ...

There's _four_ ways to do it in HTMX. Each "more sophisticated" than the previous one. Which is one really wants, sophistication, isn't it?

https://htmx.org/examples/update-other-content/

I really struggle to decide which example is worse. Not only the backend needs to be aware of the immediate frontend context, it also needs to be aware of the entire markup.

In example two, a seemingly innocuous renaming of the id of the table would break the feature, because the backend uses it (!) to update the view "out of band".

I'm really trying to be charitable here, but I really wonder what niche this is useful for. It doesn't seem good for anything complex, and if you can only use it for simple things, what value does it bring over plain javascript?