It's far better to use something that at least embeds the templates in the web page with some simple js to show it (eg alpinejs) and a simple, private API.
Why do you think the client side requires fewer partials, if you use the same scope of data changes?
I was never a JS fanboy but the modern JS/TS frameworks that let you organize and test the UI without an entire system running is better for maintenance imho.
It’s a non-point.
Do you think we have a bunch of HTML files spread out everywhere, and that we aren’t generating all of those endpoints automatically? We don’t even write 95% of the endpoints with HTMX. They’re generated from the ORM class.
It was amusing when I heard about RSC, since we’d basically been doing that for years at that point, except in whatever language the backend team is already well versed in.
If I need to add one boolean variable to a page, in React/Vue land I need to update 7 files and create a mutator and a fetcher and an actor and a dispatcher.
In HTMX land that one added variable requires editing, one file…
State was just an illustrative example that “writing a thin HTMX layer” is not necessarily a bigger lift than “just use a framework”.
There’s a big gap between “write some small thing in PHP” or whatever your team knows, and “learn React well enough to do it the right way”.
As the person I replied to said, it’s not about what’s possible. It’s about getting something done today.
We don’t write 95% of the endpoints. They’re auto generated.
And this may be a shocking idea to you, but when we do need to build a custom endpoint, we still build it as a component (just like you would in React).
This means you have a single template per page and only need to split out partials for things that are actually shared, rather than for every action on a single page.