5 ms·
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
by lewisjoe 7y ago
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?
- bananabreakfast 7y agoWasm isn't capable of manipulating the DOM yet.
- lewisjoe 7y agoYes, but it can send commands to construct and manipulate DOM. See - https://github.com/yewstack/yew https://github.com/yewstack/yew
- BinaryIdiot 7y agoRather 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 7y agoThis 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 7y ago> This is called “graceful degradation”, Isn't that strategy "progressive enhancement"? https://www.w3.org/wiki/Graceful_degradation_versus_progressive_enhancement https://www.w3.org/wiki/Graceful_degradation_versus_progress...
- irq11 7y agoYes, 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.
- sim_card_map 7y ago> SPA, Components and functional programming is the best thing that happened to web development in the recent past. Citation needed.
- ehnto 7y agoI 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 7y agoThe whole point of SSR is SEO and increased performance.