Isn’t that just pushing the complexity somewhere else? The selling point of HTMX is that it’s simple because you don’t need to deal with frameworks or JS, just write HTML! But if you have to start adding layers to support it then all that’s happening is the complexity is being moved out of the framework and into your code. Stone soup development…

I get what you mean, but for me the target is not deciding if htmx is up to x standard, but getting things done. Writing a thin layer as described above solves these issues for me.

Yes. Writing a thin layer is a minor task, compared to say, introducing a client-side store and trying to manage all of the complexity of state synchronization.

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…

I don’t understand what HTMX has to do with state synchronization. If you want to implement a thin client authoritative server architecture in React (or another JS framework), you can just do it that way. React doesn’t have any opinion on how information flows between client and server. State in React is optional, you can do everything with props if you want to.

You’re right. It can be done with React, if your team knows React.

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.

It's more just the fact that a single page gets unnecessarily split across multiple files (where there's no reuse with other pages). It makes refactoring difficult and slows development IME.

How is this different from React? Every page in the app is made up of components from numerous other files.

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.

Having some sort of typing of tgese fragments would help finding all their uses and refactoring.