Understanding React: Server-side Rendering vs Server Components
What’s the difference, in React, between Server-Side Rendering and Server Components?
For a while, I had trouble identifying the difference between the two. It kept bothering me.
On the surface, both seem very similar. They both happen on the server. They’re both intended to render content faster.
However, the documentation for server components explains that these technologies serve different purposes and operate at different levels. The two concepts are independent. You can have Server-Side Rendering (or SSR) without Server Components and Server Components without SSR. (And, of course, you can have both or neither.)
So, how can we understand the difference between the two?
The day I understood the difference between the two was when I focused on what is different in the two names, not what is similar. That might sound stupidly obvious, but trust me, it makes sense. Let me explain.
We’ll go through what each is using a practical example. Let’s say we have a ToDo app. We have a simple page with a header, the user’s profile picture in the top right, a side menu, a footer, and the to-do list in the main pane.
In React Terms, this is a component tree: the main component (for this example) is the page, which contains the header, menu, footer and main pane components. The header contains the profile picture component, and the main pain contains the Todo List component, which contains each Todo Item component.
What is Server-side Rendering (SSR)?
Now, when Next JS did Server Side Rendering (before Next JS 13), it ran a full version of client-side React on the server. However, it had a very specific entry point: the page component.
So, in our todo app example, the whole component tree is rendered to HTML on the server before being sent to the client's browser. This has several advantages: The initial load is fasterbecause clients get the entire HTML, so they see a fully rendered page more quickly. It’s SEO-Friendly: Search engines can easily crawl SSR pages, improving the site's SEO. **The client-side load is reduced **: The server does the heavy lifting, so less work is required from the client-side JavaScript to render the page.
Now, there are still drawbacks. You still depend on client-side JavaScript if you want the page to be interactive after that initial render. And that is where Server Components come in.
What are Server Components?
You see… The new thing about Server Components isn’t the “Server” part. It’s the component part.
NextJS’s server-side rendering would take the whole page, the whole component tree, and render it to HTML. This makes it suitable mainly for the initial page load. But less so for subsequent updates on the same page.
Server Components can each be rendered individually.
Now, it’s worth noting that they don’t output HTML, at least not by default. We’ll come back to their output later.
First, why is the “component” the operative, important part of the name? Why is that important?
Well, as Astro’s “islands of interactivity” model banks on, for many use cases, a large part of a web app is static or only has minimal updates.
If we look at the Todo app example, the header, side nav and footer parts are static, past the initial load. The only dynamic part is the central pane with the ToDo.
React Server components mean we can add or remove a Todo item and only update the part of the component tree that has changed.
Server Components allow developers to render specific parts of the UI on the server and then update only those parts as needed. This has a number of cool implications. It means that:
-
You can do fine-grained updateswith less data transferred because only the components that need to change are updated.
-
There is less client-side code since components that only run on the server don’t need any client-side code.
-
Data Fetching is simplerand dare I say it, more rational since server components are in charge of fetching their own data. Before Server Components, I would have to fetch all the data in the Page component via the
getServersidePropsfunction, then trickle it down via props to all the components.
At a high level, SSR is about rendering the initial page, while Server Components are about dynamically updating specific parts of the UI without reloading the entire page.
Now, if you take the time to think about it, there is still a missing piece to the puzzle. If we’re not rendering all the page’s HTML on the server, how does the browser know to update just the component’s HTML?
Do you remember how I said that server components don’t output HTML by default?
The format React Server Components output is a streamable text format that looks like bits of JSON. (For those wondering why they didn’t just use JSON, that would be a lot harder to stream).
This means some JavaScript somewhere is deserialising the special format to HTML. But that JavaScript is … generic, not specific to any given component.
Compared to the hydration that Next JS would do before Server Components, this is a lot more lightweight and targeted. React Server Components allow us to update targeted interface sections without sacrificing speed or security.
Because the interesting word in React Server Components is “Components”.
Now I hope that makes it as clear for you as for me. If you still have questions feel free to let me know in the comments, and in the meantime… I’ll see you in the next video!
