Woah I think this is misinformed on a very fundamental level, and I really would like to clarify where this idea is coming from (is it from a "modern" React or other JS-first bootcamp line of thought by chance? Not trolling, but genuinely interested). The entire point of the original web is that you send HTML to a browser rather than JS snippets or JSON payloads, and that you compose your documents from HTML fragments. "API servers" and RPC were concepts from before HTML, and the web as an app platform was welcomed for leaving granular request/response roundtrips behind and compose accessible and searchable HTML pages with really simple means (like shell scripts) on the server in the first place!
I've built web apps that didn't need much interactivity just using a regular ol vanilla web server sending html and then bootstrap.js for the menus, modals, etc.
When a client wants the interactivity of a full-on application, I would use an application framework at that point.
Using a system where the server needs to send back snippets of html for transitory states seems like you'd need to build yourself kind of a framework to handle the mechanics of that on the backend anyway. I'm not sure what the point is then. Sure, there is an asset in your project that is "just html" (the first loaded page), but you're going to need snippets of the interface's various states in different files so that the server can send them back.
It's like this framework is pursuing an aesthetic goal of "just html" which breaks when you actually try to use it for the stuff that you'd use a framework for.
