> If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it.

That is a different point than you made earlier in your comment though. That you start building an API on the server side does not mean you’re creating a good, well-balanced, API suitable for public consumption (being consumption in other teams or even other companies).

HTMX is sort of like a spiritual grandchild of 1990s stuff like CFML, at least conceptually, anyway. That's pretty cool. And maybe instructive, to look at what brought down systems like that, way back in the day.

I'm a flunkie from the caverns of the military industrial complex, but I'm also poking my head aboveground and going through some of my buddies' modern doc projects (along with the git history, issues, all the Swagger stuff [which I like!]). All in a (probably futile) attempt to be employable outside my industry. Anyway, I came away with this nagging sensation that the API is where the actual architecture work takes place. It's almost certainly a wrong impression - this is not my world - but I'm having a hard time seeing what keeps things on the rails aside from the API process. I'm getting a whiff of that from the OP article too.

I am betting that better managed projects have a whole layer specialized for architecture, instead of shoving that work down for the API docs to figure out. Nothing as stupid as what we got in our business - "fifty different architectures in a hundred different places each of which costs millions of dollars" - but a place where it theoretically happens.

This is actually a feature. A good API for public consumption is a specific thing to build with intentionality.

If your tech stack forces you to build an API in order to put a basic webpage together and handle form data, that is the red flag.