> The opposite is true.
Kind of.
A lot of the apps I work with have front-ends developed by one team, and those rely on back-ends developed by one or more teams. Serving server-rendered HTML is not a great option in this case (as much as I loved the "3270 way" of 1990's web). As client-side complexity increases, it starts to pay off to build on foundations that add more functionality, such as React, Vue or Angular, the same way some teams will prefer TypeScript over vanilla JavaScript. Adopting a well known framework makes easier to onboard new team members, as nomenclature and organization are already known to them. And, while we are at it, the team in charge of the visual representation will appreciate ways to better organize their CSS files, and, if possible, just serve a single CSS assembled from a set of files with definitions organized by subject or function. A build step allows an application to be served with files that define only the functionality needed, leaving most of the framework behind.
Not all web applications require it, of course, but I wouldn't say the expectation is to build a web application with bare HTLM/CSS/JS.
> A lot of the apps I work with have front-ends developed by one team, and those rely on back-ends developed by one or more teams
I hope that one effect of AI assistance will be that we can go back to full stack teams again. It should be easier to know enough about both sides to be productive in them with AI help.
Then things like backend templates + HTMX would maybe work great for 90% of apps and be vastly simpler than the huge pile of technology we've been using in the frontend.
> we can go back to full stack teams again.
Not sure it'd be good. We'd only be hiding complexity, not actually removing it. The ideal scenario would be that both front and back ends could be described in simple enough terms a single team (and less than two lifetimes of training) could handle it.