Check out a free preview of the full Progressive Web Applications and Offline course:
The "Server-side Rendering" Lesson is part of the full, Progressive Web Applications and Offline course featured in this preview video. Here's what you'd learn in this lesson:

Mike reviews server-side rendering for a single-page application.

Get Unlimited Access Now

Transcript from the "Server-side Rendering" Lesson

[00:00:00]
>> Mike North: The idea of server-side rendering is you are not going to have static-hosting, you're going to have a rendering server. And you're going to hit it, and depending on the path of the request that comes in, a particular view is going to be rendered. And oftentimes you will even take the users cookies into account, all right?

[00:00:19] So it could be, for this user show me the LinkedIn feed with all of the articles in it. As soon as you start going into this area, you have to have a keen awareness for what is the core JavaScript language, versus things that are conventions generally available in JavaScript environments, like set time bound.

[00:00:43] Versus things that our browser only constructs like AJAX. If you need to use AJAX for something like jQuery which depends on a full DOM implementation, your server side rendering code is going to be really really slow. You have to bring in like tons of stubbing and DOM simulation stuff to make that work the way you would expect it to work.

[00:01:09] So we don't get anything that's on the window object, we don't get Navigator we don't get sensors. We don't get screen width and screen height, those mean nothing, so if you have a pinterest layout where you have a different number of columns on the screen. And there's really not a good way to render that, at least the first time, on the server.

[00:01:30] And the typical approach there is to remember what the user's window width used to be, put that in a cookie. And now subsequent requests can at least have that as a starting point. Not a great solution, but it's all we've got so far. Keep in mind that, this dramatically slows down the initial HTML response.

[00:01:51] Wat's on the critical path to returning HTML? Booting your app, going and getting data, rendering all of those components, waiting for everything to settle, scraping that HTML, building the response object, and sending it back to the browser. It is way, way slower than rendering HTML with PHP. It is a lot of work that you need to do.

[00:02:16] But the advantage here is that we can, when we make a request to this rendering server, its gonna like inside the data centre really fast network request across the some fibre optic cable, low latency. To assemble all the data it needs, and then we gonna have all three milestones at the end of getting index.html.

[00:02:39] The idea is, even before we download client side JavaScript, we've got our grocery items already in the HTML. And the JavaScript comes down later and imperceptibly to the user, it sort of just picks up and replaces the HTML with whatever it needs to replace it with. And there's no blink or flash, but at that point, the client side is in charge.

[00:03:05] And at this point it's just sort of subsequent behavior. Subsequent things that happen beyond that page.