Check out a free preview of the full Complete Intro to React, v3 (feat. Redux, Router & Flow) course:
The "Why Use Universal Rendering?" Lesson is part of the full, Complete Intro to React, v3 (feat. Redux, Router & Flow) course featured in this preview video. Here's what you'd learn in this lesson:

Since the application relies heavily on JavaScript for rendering, the site cannot be seen without JavaScript turned on to view the application. Brian discusses how Universal Rendering can solve this problem making the application more versatile and accessible.

Get Unlimited Access Now

Transcript from the "Why Use Universal Rendering?" Lesson

[00:00:00]
>> Brian Holt: So we've written our entire application. We did React first, then we integrated Redux, and then we did Flow and all that kinda fun stuff, and we're gonna kinda take it down the final stretch here and do a couple more build-oriented sort of things. The first thing that we're gonna do is universal rendering, also formerly known as isomorphic rendering, also formerly known as a bunch of other really dumb terms.

[00:00:23] Let's stick with server side rendering because that's actually what we're gonna be doing. We're gonna take React, and we're gonna take our application, we're gonna stick it in Node and say render this out to a string so that when you go down to the client you have fully rendered mark up.

[00:00:37] So kind of to demonstrate to you here, if I view page source here, that is 100% of the HTML that I'm sending down to the user which is nothing, right? It's just the shell that React them bootstraps itself and renders out to the dom. To be honest with you this is gonna be fine most of the time, server side rendering is by no means required, right?

[00:00:59] However it's going to improve perceived load time, right? We're playing a psychology game here with our users, right? We want them to think that our webpage is as fast as possible, right? So if I send down complete mark up the browser will read it, it will render out your mark up, and then behind the scenes React is gonna hurry and bootstrap itself and then make your page interactive, right?

[00:01:24] So it's kind of a game a little bit, right? It's a game in the sense that the user sees the page rendered and it's not actually interactive yet, right? If they click on the buttons, the JavaScript is not yet there to be interacted with, right? But by the time hopefully that the user sees something, makes a decision in their mind, does like, I´m gonna click on that button.

[00:01:47] And by the time they actually move the mouse to click on the button, hopefully by that point your JavaScript will have downloaded [INAUDIBLE] attached to all of the dom, and then it'll be ready to happen. Usually, that's the case, right? So the user thinks that the page is faster, despite the fact that the time to interactive, right?

[00:02:06] The time that it actually is ready to be clicked on is gonna be about the same if not even a tiny bit slower, right, cuz you're sending more HTML. React is having to do a little bit more, all that kind of stuff. That´s what we´re gonna do, the key here is that this requires Node, right?

[00:02:25] So if you´re writing Rails, Rails really doesn´t have a way to run JavaScript, at least not directly that I´m aware of, same thing with Java, etc, etc, etc, right? So you´re gonna need Node in here somewhere to be able to do. So something that a lot of companies will do.

[00:02:41] Say for example you do have like a Java back end, that introduced what we call a node middle end or this that's what I called. I don't know if other people call that, but you'll have like a node middle end, right? So you have this node server that makes request to our API server, your Java server, your rail server It gets all the information there in the node middle end.

[00:03:00] It'll do your service at rendering for you and then send down complete workup. So, that's always a possibility as well, I would say it's pretty common. It also helps if you just run in node in the first place because that just works. Cool, so I wanna tell you that server-side rendering by itself is actually not terribly difficult to do.

[00:03:22] So if we go to, I'm gonna just pull up on my other repose here, /btholds/ I think it's the es.
>> Brian Holt: I think it's this one. Okay yeah, so if I go to the GitHub project here, I'm just gonna show you an example of server side rendering that's a lot more simple than what we're gonna do today.

[00:03:50] So I'll make this larger
>> Brian Holt: So I did this with COA, you could easily do this with Express. Really the big key here is 21 and through 24. You just say reactdom server RenderTheString, and then you pass it the React app, right? It's going to go through and render out your app to a string and then you just put that in a template.

[00:04:16] And you send that down, then end, that's it. So React's server side rendering, at its most basic, is really just that, that is to say, not a whole lot. However, we kinda have a strange issue here that we're doing client side routing cuz we're using React's router. And so the fact that we're using the client-side router introduces a little bit of complexity, because we don't have to write the routing code twice.

[00:04:45] Now if you're into it, if you want to, right, you can totally write a server version of the routing and then you can go and write a separate version of clients I'm routing, and just try and keep those in sync. I'm gonna say that's usually a bad idea, right?

[00:04:59] Cuz, something that I say all the time is like, if something has to be kept in sync it's always going to fall out of sync, like that just always happens it's a really prone to bugs to do it that way. So it's really great if we can make React router handle both server side routing and client side routing.

[00:05:17] And the answer is you can, that does work.