> The alternative of doing things old school with server side templates is ok, but it massively slows down your iteration speed through reliance on tight coupling between backend and frontend.
This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and backend teams then it slows down.
Why can't the server-side template rendering code consume an api as much as frontend JavaScript can? I don't see any reason for this to happen in the browser.
Probably because of how awkward it is. You essentially have this weird html-emitting "client-server" moving part in a limbo where it's still a one-to-many server. And it has to duplicate client code you probably still need anyways in the Javascript that runs in the browser (and, don't you want to do take advantage of some client benefits like being able to work offline or cache locally?). And this bonus moving part is only for your web clients, not something you use for any other client (iOS, Android, etc).
NextJS is something that folds over some of this, but it's not without its issues.
Of course, no better way to find out than try it for yourself. When I have the question of "why don't people just do X?", trying X myself is a quick way to realize why, and unfortunately it's never because I'm the first genius to have thought of it.
Check out Turbolinks which does load and replace the html body from the server and leaves the head content in place, thus preventing the re-evaluation of css and is at each pageload.
The first time I got even close to a custom web page (internal request system for our team), the devs did this. They wrote it as two Bottle (python) applications: One was the API for the app, the other was the delivery of the Javascript to the client, which called the API.
the template rendering lives side by side with the controllers, why would it make an api call?
But something similar but not the same as that was the norm during the jquery era before the early js frameworks arised (backbone, ember et all). You had your full-stack server-side MVC framework render initial views and from there the js would pick up and all UI interactivity would be ajax calls to the restful(ish) api. It was pretty terrible.
Because this introduces clear separation of concerns? You don't need to make this API call via HTTP, you can just call a function. You don't even need to generate/parse JSON!
I know that because this is what we are doing. Just calling a function called "httpapp". :)
Well, but then it's not the same api call and that's the point: that in the old mvc frameworks it was painful having to support controllers that both rendered html and json for doing both SSR and Ajax.
Around the time the first js FE frameworks came out, people finally became confident enough to have pure js clients and only json APIs.
And finally gatsby, next.js, etc. brought a new twist to the SSR and Ajax api combo.
This depends on project size. If a single team is working fullstack then using server side templates gives seriously faster product development iteration. Once you get to more than 5-10 devs and you want separate frontend and backend teams then it slows down.