Server Side Rendering at scale

&gt; Rather than waiting for the client to download a JavaScript bundle and render the page based on its contents, we render the page’s HTML on the server side and attach dynamic hooks on the client side once it’s been downloaded.<p>The fact that they don&#x27;t make a reference like, &quot;hey, ya know, how _everything_ worked just a few years ago&quot; tells me they think this is somehow a novel idea they&#x27;re just discovering.<p>They then go on to describe a convoluted rendering system with worker processes and IPC... I just don&#x27;t know what to say. They could have built this in Java, .Net, Go, really any shared memory concurrency runtime and threading, and would not run into any of these issues.

This article is just embarrassing. How is a internet tech company so bad at producing basic static webpages? Nothing on the Yelp site needs React or a massive frontend framework.<p>No real-time updates, no complex rendering, no serious in-depth application abilities. The only big JS feature is the maps which can be wired up with relatively little code.

I wonder why their old system couldn&#x27;t scale more horizontally so that there&#x27;s &lt;50 req&#x2F;s per service instance in order for the system to GC properly<p>Although to be fair &lt;50 req&#x2F;s&#x2F;instance is pretty bad performance so a rewrite is probably warranted

The browser still runs XML with XSLT stylesheets. What if devs would generate XML view models from the server and use XSL AKA functional programming to render HTML? and then just use Javascript to update the XML or XSL stylesheets and let the browser do its magics? Did anybody ever attempted to write SPA like that?

I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck.<p>It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy.<p>It&#x27;s unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. But that shouldn&#x27;t invite someone to stack more server javascript on top of it. Maybe someday someone is brave enough to write a frontend framework that uses a compiled language (rust, go, java?), that can also compile to javascript for the client, but renders crazy fast in ssr.

I can&#x27;t believe this madness. Is it worth? What if you just didn&#x27;t build an SPA?<p>But pretty sure some engineers are having tons of fun building this stuff there. good for them and their CVs.

I thought the cool thing these days was SSG.