I think one understated advantage of serving plain HTML is the reduced surface of things that can go wrong. Once you see that the server has sent a "200 OK" res

I think one understated advantage of serving plain HTML is the reduced surface of things that can go wrong. Once you see that the server has sent a "200 OK" response you know that everything is good and the user will see the content (okay, you still need to worry about the CSS and images loading). In contrast, with a single-page application everything is asynchronous. Have you handled all possible error cases and race conditions? Have you thought about all of the possible immediate states (e.g. one remote call being super slow might cause the UI to be inconsistent/confusing)? And all of this logic is running on the client. And that client might also be out-of-date (if they left the tab open). So much complexity! Another side-effect of server-side rendering is that it forces you to make it performant. I've seen so many SPA with a mind set of "oh, this data isn't critical so it doesn't matter that it takes 2 seconds to load; we'll just put it behind a spinner". Over time this has a tendency to cause applications which does massive amount of slow remote calls to different servers/services and multiple spinners in all components. Good luck trying to use these on a mobile phone in transit… Once you put all of the content inside a single call to the server you can't get away with this and you preemptively need to care and focus about performance. There are of course many advantages to using SPA, but for me I don't think it will ever give me the same calmness as with server-side rendering where I can see all requests in the last 24 hour being successfully responded in <X ms.