[lewisjoe]

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?

[BinaryIdiot]

Rather than running JS on the server, one way I found things to be effective is using any server side templating capability to basically "bootstrap" what the JS might typically do on start-up. So the server renders you a page that looks well formed and then the JS hooks into it for client interactions.

The issue that can be runned into here is possibly duplicating efforts on the server and JS side. You can keep them separate enough but it's tough if you're used to creating everything either through the server or through JS on the client.

The last web app I worked on like this is unfortunately not public but performed rather well and wasn't all that difficult to maintain either.

[irq11]

This is called “progressive enhancement”, and is, in fact, the way that you’re supposed to write webpages: they should come pre-rendered, and only if the client has JS enabled do you enable more dynamic features. You fall back to full pageloads to handle form submissions with not-very-clever coding, and can usually preserve most of the functionality of a webapp even without JS.

Until about 5-6 years ago, this was the way people tried to write webapps (they didn’t always get there, but at least they aimed for it). It’s really startling that it’s something that people have already forgotten.

It really isn’t terribly difficult to do this. Frameworks like Rails make it pretty easy to do, out of the box.

[arvinsim]

> This is called “graceful degradation”,

Isn't that strategy "progressive enhancement"?

https://www.w3.org/wiki/Graceful_degradation_versus_progress...

[irq11]

Yes, it is. I corrected my post around the same time you replied. I’ve colloquially used the term I originally cited, but the correct term is progressive enhancement.

[ehnto]

I thought the selling point of React SSR was caching and pre-rendering into static HTML? How is it being used that causes it to become a performance bottleneck?

[JDiculous]

The whole point of SSR is SEO and increased performance.

[bananabreakfast]

Wasm isn't capable of manipulating the DOM yet.

[lewisjoe]

Yes, but it can send commands to construct and manipulate DOM. See - https://github.com/yewstack/yew

[sim_card_map]

> SPA, Components and functional programming is the best thing that happened to web development in the recent past.

Citation needed.