This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…
> single language applications are single build applications I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vic…
We view it as a massive advantage, assuming we are on the same page with "single language, plus HTML/CSS/JS"
Our language is C#. Our web "framework" consists of the string interpolation and verbatim operators. Most of our views take the form of:
var finalHtmlResponse = @$"
{DiyPHPViewEngineRabbitHoleEntrance(httpRequestContext)}
";
I actually tried using the cshtml/razor engines because it seemed "more proper" but after 2 days of dependency hell I decided to go back to raw string interpolation. If you are able to build a functional website using static sources and have the barest capability to compose functions and strings, I do not see why this path would provoke any serious anxiety (other than it not being popular).Imagine being able to directly invoke some utility or other backend method from your HTML view source pipeline. If you write it all in the same language, this becomes feasible. The moment principal rendering is outsourced to the client (or some other language), you are talking about a JSON API + distributed state circus and all the hell that must go along with it.