[pas]

HTMX is nice if you really really really want to couple your backend to whatever happens on the frontend.

And yes, yes of course, it makes sense for at least half of whatever anyone is doing nowadays. I'd even go as far as to say that HTMX with the microfrontends idea is the ideal for large organizations with microservices-like independentish features.

... that said, there's a good chance that eventually HTMX will become a WASM kernel capable of transmogrifying a well-annotated OpenAPI endpoint into some kind of UX-positive behavior. And at that point we can, again, finally free the forms from the frozen frontend frontier!

[lurking15]

I'm not even convinced that Javascript + JSON fat client architecture is decoupled. It hides the fact that the browser is for better or worse a hypermedia client.

[pas]

It's a spectrum! (Insert bell curve meme with "everything is connected" on the tails and "noo! that's too coupled" in the middle ! :D)

It's also a lot of trade-offs in a big bundle. (How many people will work on the codebase? At the same time? Is the problem well-defined enough to agree on an API? How much "API evolution" are we expecting? Are there going to be wildly different user journeys based available based on state? Is this Roy Fielding persona in the room with us now? How experienced the developers are? What tools do they know well? How's the infra/devops/deployment story? Do we need to setup Maven and rebuild the whole J2EE JAR/WAR thing in order to change the CSS? Insert everything is an optimization problem meme! :`] )

And whatever stack a particular project ends up picking is just the current culmination of roughly two decades of very strong path-dependence, which itself is a result of a very weird non-cooperative speedrunning through various iterations of these problems. [0] And while the ecosystem will happily continue to churn the project will likely not have the luxury to rewrite everything every few years, so the developers ought to pick something they are comfortable with for the next X years. (And to solve for X we need to know whether this is a personal project or it's the current flagship darling of a soon-to-be multi-trillion dollar company...)

[0] For example both Flash and Java have been sent to sleep with by JavaScript, because they were not able to coevolve with that scrappy thing which was initially thrown together by in 10 days. So it made a lot of sense to not pick JS, and to keep as much as possible on the server-side, or pick Flash for some amazing UX! But the JS engine was eventually secure and built-in to every browser and JS code could be delivered fast.

[roncesvalles]

Having a "backend-for-the-frontend" is unavoidable even in a SPA. Your real backend starts behind that.