7 ms·

A Gentle Introduction to SSR

46 points by jgalvez 4y ago

m12k 4y ago
In this context, SSR is Server-Side Rendering, not Screen Space Reflections.
- chapliboy 4y ago
  I was hoping it would be Stephen's Sausauge Roll.
  - quickthrower2 4y ago
    I was hoping for Soviet Socialist Republics
- dncornholio 4y ago
  And the context of "Server-Side Rendering" defaults to JavaScript.. Like PHP, Django and Rails don't even exist
  - balabaster 4y ago
    Along with a host of other server side "languages" - ASP, PERL/CGI... all this has been done before. Just as we've come full circle on infrastructure where we were trying to eke every ounce of performance out of memory and CPU cycles because supply was short, now we do so because we're charged by the cycle, memory overhead, bandwidth we're beginning to recycle concepts like server side rendering... which has been done since as long as PERL/CGI existed back in the 90s. It's funny how we just keep reusing the same ideas and calling them new... it makes me wonder why the history of relevant technologies aren't taught in software development classes so we can actually forge a path forward instead of keep doing the same things over and over again...
- MezzoDelCammin 4y ago
  and there I was, with my hope of finally getting to understand Solid State Relays...
_han 4y ago
I recently learned about SvelteKit's (https://kit.svelte.dev/ https://kit.svelte.dev/) solution to mixing SSR with dynamic components: The dynamic component is rendered at the server, but the data that it's based on is included with the HTML. So, after the page loads, it converts the static HTML into a dynamic component using the data, in a process called 'hydration': https://kit.svelte.dev/docs/appendix#hydration https://kit.svelte.dev/docs/appendix#hydration
- alessioalex 4y ago
  Hydration is how most (if not all) similar frameworks do it (Next, Nuxt etc).
  - eyelidlessness 4y ago
    Not all. One mentioned in the article, Qwik, uses a different technique the authors call resumability. It’s similar in that it applies JS to components client side which were rendered with the same code server side. The subtle differences: - it derives its initial client state from the HTML, rather than re-running the initialization which already ran on the server - it doesn’t render top down, it resumes interactive components on demand (on first user interaction by default) - it doesn’t load any of that code at all by default; if your page is fully static, none of the code ever gets loaded This is similar to frameworks like Astro which use a technique called “partial hydration”, but with Qwik it’s handled by the compiler. Another which is somewhere in between (and has been doing all this for years; I’m not sure exactly where its most recent release sits on the spectrum) is Marko.
- davidkuennen 4y ago
  Doing the same with React[1] for my website[2]. Notice how the elements on top are dynamic, but the whole content is loaded upfront. [1] https://reactjs.org/docs/react-dom-server.html https://reactjs.org/docs/react-dom-server.html [2] https://stockevents.app https://stockevents.app
- sirsinsalot 4y ago
  When backbone.js was the new hotness, you used to do this by templating out the page (in PHP or whatever) and including in the head some JSON that the page picked up on client-side render. It is all common sense, and I feel like the language reinvention is an attempt to make old things new, not new things better, because everyone wants to performatively demonstrate how far up the curve they are.
jdrc 4y ago
What if we just implemented PHP on the browser instead?
- imiric 4y ago
  Done: https://github.com/seanmorris/php-wasm https://github.com/seanmorris/php-wasm
  - arethuza 4y ago
    Server side WASM appears to be thing as well. https://www.infoq.com/presentations/wasm-server-api/ https://www.infoq.com/presentations/wasm-server-api/ So that would allow you to run PHP on the server as well ;-)
kookamamie 4y ago
Was hoping to read about Screen-Space Reflections.
zelphirkalt 4y ago
> Server-Side Rendering comprises various techniques involved in running JavaScript universally or as some like to say, isomorphically, that is, both on the server and on the client [...] I am like: "Did they just redefine SSR to limit its meaning to something JS specific, when it was the default for decades?" Then: > [...] — in order to pregenerate markup for delivery and spare the browser from having to do so dynamically on page load — this is my definition, you'll find many others, but I think this captures the gist of it. Ahhh, their own definition! OK, it is rather weird to limit SSR to be something JS specific, when people have been talking about rendering HTML on the server side for decades. Most web frameworks are able to make use of some kind of templating language, of which there are hundreds, if not thousands. Often they are interchangable and not a hard dependency of the web framework.
- fuzzy2 4y ago
  I think the SSR term is very much tied to SPAs. It is the process of (pre-)rendering a SPA on the server. So until a WASM SPA framework comes around this will be limited to JavaScript, yes. Because SPAs must be JavaScript. Sure we were generating HTML on the server since basically forever. But that’s not SSR (in the sense that there is no client-side rendering).
  - chrismorgan 4y ago
    The term “server-side rendering” was in common usage when people started implementing client-side rendering more commonly in the late ’00s and early ’10s. But in the last five years or so, the term has been appropriated by the isomorphic rendering crowd so that “SSR” or “Server-Side Rendering” normally means server-side isomorphic rendering (that is: server-side operation of something that’s primarily designed for client-side rendering), and there’s no standard term any more for pure server-side rendering, though if you write it lowercase it probably means the old-school technique.
    - arethuza 4y ago
      Is it really fair to call something that is used so widely by major sites "old-school"?
trhoad 4y ago
@Author, nice article, but the bold yellow italics make reading quite difficult (e.g. Why is "gist" emphasised?).
- chrismorgan 4y ago
  I certainly found the article much easier to read when I turned it to black-on-white with no exuberant bolding and colouring of italics and the likes.
- jgalvez 4y ago
  Fair enough, I'll try and find a better combo there!
zmxz 4y ago
It feels like we're running in circles. We used languages like PHP/Ruby to produce HTML/CSS that browser renders. Then Microsoft introduced XHR. Then we started with "saving bandwith" and "page does not to be reloaded" and AJAX was born (although it was Asynchronous HTTP and HTML instead of XML). Then such sites weren't indexed by Google so we started to pre-render content again for the most visited URLs. And now there's so many buzzwords and bland excuses about server side rendering, such as "SSR improves user experience: users don't have to wait for CPU-bound JavaScript to run on the client". JavaScript itself is not what makes websites slow. It's the 50 megabytes of advertising material I've to load from various "content delivery networks" that are everything except fast and auto-play videos that I'm not interested in. Today's personal computers are stupidly fast, smartphones too. There's so little gain in the argument that pre-rendering the first request on the server improves performance while it does nothing for the network-related problems (resolving the domains and transferring so much content). SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). Yes, it does improve user experience, but it doesn't do so because our computers are slower in parsing and executing JavaScript.
- quickthrower2 4y ago
  SSR feels like it feels a niche where you have public, dynamic and seo sensitive data. If it is not public (like a web app you log into say canva) then SPA is fine and for most public stuff static pages (generated or cached dynamic pages) are fine.
- sdevonoes 4y ago
  > SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we want developers to use the same language, libraries and frameworks in the frontend and in the backend. I just don't know which kind of developers are those who cannot bother to learn something else besides JS/TS. I have heard many times the argument "we are saving developer time by using the same technologies everywhere!", but I just don't buy it.
  - trinovantes 4y ago
anyfactor 4y ago
I expected this to be an ELI5 easy to read explanation of SSR because it mentioned "gentle introduction". But the explanations and keywords in the articles would demand their own "gentle introduction". How the heck this is a gentle introduction of anything. > Server-Side Rendering comprises various techniques involved in running JavaScript universally or as some like to say, isomorphically, that is, both on the server and on the client — in order to pregenerate markup for delivery and spare the browser from having to do so dynamically on page load — this is my definition, you'll find many others, but I think this captures the gist of it. Maybe I am too stupid, but I would rather read a wikipedia article on SSR at this point. https://en.wikipedia.org/wiki/Server-side_scripting https://en.wikipedia.org/wiki/Server-side_scripting
bjarneh 4y ago
We need to find another term for this (Server Side Rendering = SSR). SSR is starting Firefox on a server with X-forwarding or something. How is producing a complete HTML document on the server = rendering? Then PHP has been rendering webpages for years. Offloading the actual rendering-engine from gluing together the HTML document from parts fetched or produced by Javascript prior to actually rendering the webpage can probably be a good idea in some instances. But this is hardly a new technique. Using Javascript to do it doesn't make it something different than PHP or the good old CGI scripts in Perl/Python.
- arnorhs 4y ago
  Wholeheartedly agree. I actually tweeted out this morning a suggestion: HSR (Hydrated server rendering) .. i think that encapsulates the difference pretty well.. although CHSR would be more accurate, but "Client" is implied when talking about "hydration" imo
  - tatersolid 4y ago
    Back in the 90s we used to call outputting HTML from a dynamic server process “serialization”. Get off my lawn.
- kevingadd 4y ago
  Rendering doesn't have to mean generating bitmap pixels. In any case, the pixels you generate would get compressed before going over the wire. The HTML document can be viewed as an especially convoluted vector representation of the scene (in this case, a tree) that compresses things like text very efficiently. RDP does stuff like this to more efficiently transmit window contents over the wire, AFAIK - they're not just sending bitmaps.
- andthenwhat 4y ago
  Agree. I thought I was clicking on an article about screen-space reflections in 3D rendering, although CGI and Perl were around long before that so they win the race for that acronym.
deleted 4y ago
[deleted]
terrycody 4y ago
Hey, Regard "SSR improved ranking" : I think this is a myth. I mean, that simply means those static websites will rank better than dynamic sites, and in fact, this seems not real. But I get the idea, if improved the speed, thus SHOULD in theory, improve the ranking.

46 points by jgalvez 4y ago

m12k 4y ago

In this context, SSR is Server-Side Rendering, not Screen Space Reflections.

chapliboy 4y ago
I was hoping it would be Stephen's Sausauge Roll.
- quickthrower2 4y ago
  I was hoping for Soviet Socialist Republics
dncornholio 4y ago
And the context of "Server-Side Rendering" defaults to JavaScript.. Like PHP, Django and Rails don't even exist
- balabaster 4y ago
  Along with a host of other server side "languages" - ASP, PERL/CGI... all this has been done before. Just as we've come full circle on infrastructure where we were trying to eke every ounce of performance out of memory and CPU cycles because supply was short, now we do so because we're charged by the cycle, memory overhead, bandwidth we're beginning to recycle concepts like server side rendering... which has been done since as long as PERL/CGI existed back in the 90s. It's funny how we just keep reusing the same ideas and calling them new... it makes me wonder why the history of relevant technologies aren't taught in software development classes so we can actually forge a path forward instead of keep doing the same things over and over again...
MezzoDelCammin 4y ago
and there I was, with my hope of finally getting to understand Solid State Relays...

_han 4y ago

I recently learned about SvelteKit's (https://kit.svelte.dev/ https://kit.svelte.dev/) solution to mixing SSR with dynamic components: The dynamic component is rendered at the server, but the data that it's based on is included with the HTML. So, after the page loads, it converts the static HTML into a dynamic component using the data, in a process called 'hydration': https://kit.svelte.dev/docs/appendix#hydration https://kit.svelte.dev/docs/appendix#hydration

alessioalex 4y ago
Hydration is how most (if not all) similar frameworks do it (Next, Nuxt etc).
- eyelidlessness 4y ago
  Not all. One mentioned in the article, Qwik, uses a different technique the authors call resumability. It’s similar in that it applies JS to components client side which were rendered with the same code server side. The subtle differences: - it derives its initial client state from the HTML, rather than re-running the initialization which already ran on the server - it doesn’t render top down, it resumes interactive components on demand (on first user interaction by default) - it doesn’t load any of that code at all by default; if your page is fully static, none of the code ever gets loaded This is similar to frameworks like Astro which use a technique called “partial hydration”, but with Qwik it’s handled by the compiler. Another which is somewhere in between (and has been doing all this for years; I’m not sure exactly where its most recent release sits on the spectrum) is Marko.
davidkuennen 4y ago
Doing the same with React[1] for my website[2]. Notice how the elements on top are dynamic, but the whole content is loaded upfront. [1] https://reactjs.org/docs/react-dom-server.html https://reactjs.org/docs/react-dom-server.html [2] https://stockevents.app https://stockevents.app
sirsinsalot 4y ago
When backbone.js was the new hotness, you used to do this by templating out the page (in PHP or whatever) and including in the head some JSON that the page picked up on client-side render. It is all common sense, and I feel like the language reinvention is an attempt to make old things new, not new things better, because everyone wants to performatively demonstrate how far up the curve they are.

jdrc 4y ago

What if we just implemented PHP on the browser instead?

imiric 4y ago
Done: https://github.com/seanmorris/php-wasm https://github.com/seanmorris/php-wasm
- arethuza 4y ago
  Server side WASM appears to be thing as well. https://www.infoq.com/presentations/wasm-server-api/ https://www.infoq.com/presentations/wasm-server-api/ So that would allow you to run PHP on the server as well ;-)

kookamamie 4y ago

Was hoping to read about Screen-Space Reflections.

zelphirkalt 4y ago

> Server-Side Rendering comprises various techniques involved in running JavaScript universally or as some like to say, isomorphically, that is, both on the server and on the client [...] I am like: "Did they just redefine SSR to limit its meaning to something JS specific, when it was the default for decades?" Then: > [...] — in order to pregenerate markup for delivery and spare the browser from having to do so dynamically on page load — this is my definition, you'll find many others, but I think this captures the gist of it. Ahhh, their own definition! OK, it is rather weird to limit SSR to be something JS specific, when people have been talking about rendering HTML on the server side for decades. Most web frameworks are able to make use of some kind of templating language, of which there are hundreds, if not thousands. Often they are interchangable and not a hard dependency of the web framework.

fuzzy2 4y ago
I think the SSR term is very much tied to SPAs. It is the process of (pre-)rendering a SPA on the server. So until a WASM SPA framework comes around this will be limited to JavaScript, yes. Because SPAs must be JavaScript. Sure we were generating HTML on the server since basically forever. But that’s not SSR (in the sense that there is no client-side rendering).
- chrismorgan 4y ago
  The term “server-side rendering” was in common usage when people started implementing client-side rendering more commonly in the late ’00s and early ’10s. But in the last five years or so, the term has been appropriated by the isomorphic rendering crowd so that “SSR” or “Server-Side Rendering” normally means server-side isomorphic rendering (that is: server-side operation of something that’s primarily designed for client-side rendering), and there’s no standard term any more for pure server-side rendering, though if you write it lowercase it probably means the old-school technique.
  - arethuza 4y ago
    Is it really fair to call something that is used so widely by major sites "old-school"?

trhoad 4y ago

@Author, nice article, but the bold yellow italics make reading quite difficult (e.g. Why is "gist" emphasised?).

chrismorgan 4y ago
I certainly found the article much easier to read when I turned it to black-on-white with no exuberant bolding and colouring of italics and the likes.
jgalvez 4y ago
Fair enough, I'll try and find a better combo there!

zmxz 4y ago

It feels like we're running in circles. We used languages like PHP/Ruby to produce HTML/CSS that browser renders. Then Microsoft introduced XHR. Then we started with "saving bandwith" and "page does not to be reloaded" and AJAX was born (although it was Asynchronous HTTP and HTML instead of XML). Then such sites weren't indexed by Google so we started to pre-render content again for the most visited URLs. And now there's so many buzzwords and bland excuses about server side rendering, such as "SSR improves user experience: users don't have to wait for CPU-bound JavaScript to run on the client". JavaScript itself is not what makes websites slow. It's the 50 megabytes of advertising material I've to load from various "content delivery networks" that are everything except fast and auto-play videos that I'm not interested in. Today's personal computers are stupidly fast, smartphones too. There's so little gain in the argument that pre-rendering the first request on the server improves performance while it does nothing for the network-related problems (resolving the domains and transferring so much content). SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). Yes, it does improve user experience, but it doesn't do so because our computers are slower in parsing and executing JavaScript.

quickthrower2 4y ago
SSR feels like it feels a niche where you have public, dynamic and seo sensitive data. If it is not public (like a web app you log into say canva) then SPA is fine and for most public stuff static pages (generated or cached dynamic pages) are fine.
sdevonoes 4y ago
> SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we want developers to use the same language, libraries and frameworks in the frontend and in the backend. I just don't know which kind of developers are those who cannot bother to learn something else besides JS/TS. I have heard many times the argument "we are saving developer time by using the same technologies everywhere!", but I just don't buy it.
- trinovantes 4y ago

anyfactor 4y ago

I expected this to be an ELI5 easy to read explanation of SSR because it mentioned "gentle introduction". But the explanations and keywords in the articles would demand their own "gentle introduction". How the heck this is a gentle introduction of anything. > Server-Side Rendering comprises various techniques involved in running JavaScript universally or as some like to say, isomorphically, that is, both on the server and on the client — in order to pregenerate markup for delivery and spare the browser from having to do so dynamically on page load — this is my definition, you'll find many others, but I think this captures the gist of it. Maybe I am too stupid, but I would rather read a wikipedia article on SSR at this point. https://en.wikipedia.org/wiki/Server-side_scripting https://en.wikipedia.org/wiki/Server-side_scripting

bjarneh 4y ago

We need to find another term for this (Server Side Rendering = SSR). SSR is starting Firefox on a server with X-forwarding or something. How is producing a complete HTML document on the server = rendering? Then PHP has been rendering webpages for years. Offloading the actual rendering-engine from gluing together the HTML document from parts fetched or produced by Javascript prior to actually rendering the webpage can probably be a good idea in some instances. But this is hardly a new technique. Using Javascript to do it doesn't make it something different than PHP or the good old CGI scripts in Perl/Python.

arnorhs 4y ago
Wholeheartedly agree. I actually tweeted out this morning a suggestion: HSR (Hydrated server rendering) .. i think that encapsulates the difference pretty well.. although CHSR would be more accurate, but "Client" is implied when talking about "hydration" imo
- tatersolid 4y ago
  Back in the 90s we used to call outputting HTML from a dynamic server process “serialization”. Get off my lawn.
kevingadd 4y ago
Rendering doesn't have to mean generating bitmap pixels. In any case, the pixels you generate would get compressed before going over the wire. The HTML document can be viewed as an especially convoluted vector representation of the scene (in this case, a tree) that compresses things like text very efficiently. RDP does stuff like this to more efficiently transmit window contents over the wire, AFAIK - they're not just sending bitmaps.
andthenwhat 4y ago
Agree. I thought I was clicking on an article about screen-space reflections in 3D rendering, although CGI and Perl were around long before that so they win the race for that acronym.

deleted 4y ago

[deleted]

terrycody 4y ago

Hey, Regard "SSR improved ranking" : I think this is a myth. I mean, that simply means those static websites will rank better than dynamic sites, and in fact, this seems not real. But I get the idea, if improved the speed, thus SHOULD in theory, improve the ranking.