Introduction to Next.js 13+, v3

React Server Components

Scott Moss

Scott Moss

Superfilter AI
Introduction to Next.js 13+, v3

Check out a free preview of the full Introduction to Next.js 13+, v3 course

The "React Server Components" Lesson is part of the full, Introduction to Next.js 13+, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Scott discusses single-page applications, server-side rendering, and how the introduction of React Server Components in Next.js 13 solves some problems with the server-side rendering method. Server-side rendering renders initial components on the server, but requires downloading the full JavaScript like in single-page applications, making React server components more efficient for performance and user experience.


Transcript from the "React Server Components" Lesson

>> Let's just dive right in to the most craziest thing about this framework and all the things that, hopefully, we have a lot of questions on [LAUGH] and stuff like that. But I'm just gonna dive right in and kinda talk about it because I think everything going forward is based off this foundation, so I'm just gonna introduce it early on.

So there's really not a lot of context right now, but you will build the context later. And that is gonna be server components. So React server components is a new paradigm introduced in React 18 and has been adopted by Next.js 13. And basically, the whole new premise of React.js 18 and Next.js 13 with React Server Components is trying to address some of the earlier issues we've had with different types of rendering modes in the framework.

So before we get into that, let's just talk about like some of these different types of rendering modes. So the one you might be familiar with the most is called a SPA or S-P-A, single page application. This is just like, you did create React app. And you just built something with like React router or some other HTML based router and you built an app, that's a single page application.

You just have one index that HTML page in the browser and every time you do routing, you're just switching out that div with another component. But the HTML page never goes back to the server and reloads or refetches. So it's just a single page that switches out components based off of a router.

And this is really cool. This was all the crave and the raised back then because, it was quick, routing was fast. You didn't have to worry about having a server. You can put it on a CDN, different things like that. But it had problems. The browser had to download all the JavaScript in order for people to see things, not only to see things but to interact with those things.

You also have problems with like crawlers. If you paste a link to a single-page application and something like Facebook or Twitter, it might have been hard to see those previews pop up because those crawlers didn't know how to interpret JavaScript. And it wasn't gonna wait for the JavaScript.

So you just wanna see your preview. And I remember it was a time where even Google was not good at crawling single page applications. So you had all these companies that would take your app, pre-render it, spit out the HTML and then give that to a crawler, or even crazier, you do it dynamically, you create your own server, detect that like, a crawler is on my website.

Don't show them the single page application, show them the pre-rendered version instead, like that was a thing, I remember having to make that. So it was pretty nuts. So to address that, server side rendering came out, right? Server side rendering is basically kind of the same thing but with a different first step.

So instead of like rendering everything on the browser and having the JavaScript be downloaded, instead, the initial render of that page or that component happens on the server. So we're gonna take that component, render it to HTML, send that HTML to the browser, so it shows up instantly without any JavaScript download.

And then while that is being shown in the background, download the JavaScript, and then have the client version of that same component take over, which allows interactivity. And that swap happens so fast that you don't see it, but it does happen, so that way people can see the page immediately.

Crawlers can get the information that they want immediately, but you still have to wait for the JavaScript to download in order to be interactive. So we did solve the problem of seeing things quickly and solving the SEO and crawler problem. But we didn't solve the problem of, well, what if I wanna click on that form as soon as I see it?

Well you can't, cuz you gotta wait for the JavaScript to download. And depending on your Internet connection and how big the JavaScript was, it could take a long time. So then people got really fancy with like, we'll do code splitting, so we'll split the bundle up and then we'll do dynamic imports.

So we only import code that like, and then it's like yeah, but are we really solving the problem here? So, now this brings us to React Server Component which tries to solve some of these problems. So React Server Components is basically a new way of doing server-side rendering that is almost like server side rendering, except for the fact that there is no JavaScript associated with the components sent to the browser.

So you could actually run a React Server Component entirely without any JavaScript at all. But the caveat is you can't have any interactivity in your component either. You still need client components for that. But by having these server components, this allows us to do all the data fetching necessary for a page.

Imagine you have a blog page that needs to get content from a CMS. You can do that on the server while the component is rendering and send that back to the client without any JavaScript added to it. So there is no need to wait for an entire bundle of JavaScript to download just to see anything or interact.

And if there is some interaction on there, well, that interaction, that specific component that has interaction, let's say it's a form. Only that component can be a client component. So therefore, the rest of the page doesn't have to wait for that bundle to download to interact with that form just so you can move around.

So things are being progressively, what they call progressively enhanced. So we're choosing what to download at what specific time based off what needs versus like, we can only download everything at one time. Even though, this whole page doesn't need any interaction, but this one component does. But now we don't have to do that anymore.

Just download the whole page and then when this thing needs interaction, we can download that progressively, we can actually stream it. So that's kind of like what server components is. Next.js has taken that and built it into the framework. And it's actually pretty cool. It's also slightly confusing if you haven't worked in a framework that switches between client side and server side JavaScript all in one repo and it all looks the same.

So it's not like, well, this is Express over here and this is React, so I can clearly tell which one's back in and which ones front end. Okay, now that's not gonna happen anymore. You are going to be writing React components, and they could be working on the back end or working on the front end or both.

So like having to know which version is doing, what is kinda confusing, but we're gonna walk through how best not to get confused through some of that. So I'm gonna just talked about a little bit about difference between React Server Components versus server side rendering. But basically server side rendering performs that.

It only does server start reading on that initial load, right? But then if you try to go back to it, it's just gonna be client side routing, so you kinda lose the benefit of that. Whereas with React Server Components, every time you go to it, it's gonna render on the server.

So you always get that benefit of never needing JavaScript. This makes the client site bundle predictable, and cacheable, which is really hard to do if the bundle size is always changing. Now, you don't have to worry about it changing when you add new pages, because those pages don't contribute to the bundle size because they are server components.

So this makes performance basically easier to do and it's not all perfect. But for the time being, I think it's a really good experiment with the React team is doing, what the next year's team is doing, and we'll see if it sticks. If you ever built something in.

Let me see what's an equivalent like Elixir, Phoenix, PHP, Ruby on Rails. It's basically that, where you're just doing all the logic for a component executing on a server and not on a client. Yeah, that was a long spiel. I don't expect you to remember and know all of that.

We're gonna go through a lot of this in examples, but I wanted to give you that primer. So we're gonna start mentioning some of these words as we write the code, and I want you to know what they are. Cool, any questions
>> I got kind of a weird one.

Working with hot wire for rails before, like the HTML over the wire, ones that mostly use web sockets under the hood. Is that what RSC is doing too or is it?
>> So I know React 18 implements streaming of the HTML to the browser. I think Next.js has its own approach where they actually just pre-rendered instead of streaming it, the HTML, but you do have the ability to like stream data to it.

So there is no web socket's implemented here. There is no real time component of like streaming HTML, like Hotwire or like what Elixir and Phoenix, like what they do especially in Next.js. They did do the pre-rendering, but I don't think there's anything stopping you from doing it if you want it to, but I think next year is does just does the pre-rendering instead of like doing the streaming by default, but no, great question.

But as far as like, what you get is pretty much the same thing.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now