This looks like a great piece of article. Kudos to the people who wrote it because the most sure-shot problem in SSR is running to scaling issues and this is a much needed one.

But here's an unpopular opinion: Server side rendering shouldn't even be a thing. Running a language as dynamic as Javascript on servers, is at best - a problem that can be dealt with, but not necessarily the solution.

I'm saying this as a full-time Javascript developer. We can do better than mandating JS on the servers.

#1. SPA, Components and functional programming is the best thing that happened to web development in the recent past. So, let's stick with it.

#2. But we are stuck with Javascript to embrace these otherwise abstract engineering methods, because browsers are stuck with JS.

#3. Webassembly is here. So why not a UI-framework, that embraces components, SPAs and functional programming but with a better language (something like Elm). A language that compiles to webassembly for browsers to run logic & build UI and runs natively on servers? This hypothetical system should compile to HTML on the servers and support smooth progressive hydration.

Running a bunch of JS on the servers, on a piece so critical like rendering HTML will always be a suboptimal solution. Imagine saving all that server-scaling costs with a much server-cost-friendly language like Rust or Swift?

Wasm isn't capable of manipulating the DOM yet.