the RSC paradigm is complimented by SSR, but they are not the same

Much of the confusion new React developers face when reading about or using React Server Components stems from innacurate conflations with Server Side Rendering.

Above all else RSC is a paradigm, or architecture, that can reduce bundle sizes and enhance data fetching. These are the two most critical benefits to utilizing the RSC architecture, and understanding why those benefits exist is key to understanding what RSCs even are.

As an architecture, RSC needs to be implemented in order for developers to use it. Next.JS is perhaps the most popular implementation of RSCs within a framework. Without a framework, RSCs cannot be effectively used. A developer can take on the challenge of implementing the RSC architecture themselves for educational purposes, but it is unlikely that such individual implementations could ever compete with frameworks like Next.JS.

Let's first explore how RSCs reduce bundle sizes. To do so, you should have a high level understanding of how React without RSCs operates.

React

In a vanilla React application, your React component code is bundled and sent to the browser or client. That client has an instance of React, the React Client, which executes your React component code into a non-html description of the UI -- this is known as the VDOM.

Now imagine that the React Client does not need to execute the React component code into that non-html representation, imagine that the representation itself is sent to the React Client. What could send that representation to the React Client? Another instance of React that exists on another computer, not the client. This instance can be known as the React Server. This is the "React Server" in "React Server Component." So the React Server can execute React component code and send the non-html representation to the React Client to render. No JS React component code required.

Execution Environment

The environment where the React component code is executed dictates which APIs can be called in your component code -- if you are executing the React code on the browser, you can access the browser API. If you are parsing the bundle on another computer, let's say on a web server, then you can access the server API. This is why RSCs enhance data fetching -- the React component code can directly access the data fetching APIs when being parsed into the non-html description.

A Server Component

Take a look at the simple server component code below.

import fs from "fs";
  export async function ServerComponent() {
    const readFromServer = fs.readFileSync("text.txt", "utf-8");
  
    return (<div> {readFromServer} </div>)
  }

There is a lot going on in those four lines of code. First of all, the component is async. Secondly, it reads from a file that is not being sent to the browser using the fs API which is not avaliable on the browser.

Under the RSC paradigm, this component code is executed on the React Server. In the case of Client Side Rendering, the resulting VDOM compatible output is sent to the React Client which then renders the text. In the case of Server Side Rendering, that output is also parsed into markup for the browser's first contentful paint. SSR is an additional, but highly complimentary, step.

Server components can be async. RSC will wait for all promises to resolve before returning VDOM in the case of CSR or HTML in the case of SSR.

Importantly, benefits of RSC exist with or without SSR. Bundle sizes are still reduced, and server components can still access server APIs during execution of React Component Code.

CSR VS SSR

In the context of Next.js, everything in an initial page load is rendered through SSR. Only subsequent navigations trigger traditional CSR for client components. It's crucial that one does not confuse RSC with SSR as they are not the same thing. The React Server is simply an additional instance of React that sends information to the React Client such that the bundled React component code need not be sent to the client. SSR in this context means that the React component code is first executed into the non-html description of the UI on the React Server, and then additionally rendered into HTML on the server before being sent to the client. That second step which produces HTML is seperate from anything to do with RSCs, although it does greatly compliment the architecture.

Summary so far

React Server Component is a component that has its React component code executed away from the client; the output of that execution is sent to the React Client for rendering. SSR in this context means that the output of execution is sent to an additional React Client on the server, and then HTML is sent to the web browser.

So what is "use client"?

Earlier I mentioned that in Next.js every initial page load goes through SSR. In the context of client components, what that means is that an initial preview of the HTML is produced instead of the final HTML. The "use client" directive marks this component for hydration at which point it has access to the browser API. So for client components, only the initial preview is produced through SSR. The directive itself marks that HTML for hydration, or in other words attaches that HTML to the instance of React on the browser, allowing for access to APIs like useEffect and useState.

Weaving

Some of the most powerful capabilities of RSC exist in the ability to weave server and client components together. The RSC architecture and the framework that implements it intelligently and selectively bundles and executes component code.

You can call client components in server components, and only the marked client components will send javascript to the web browser. You can even pass a server component as a prop to a client component, and a properly implemented architecture will execute the server component on the React Server before serializing it and sending it to the React Client.

Conclusion

RSC is an architecture that reduces bundle sizes and enhances data fetching by allowing React component code to be executed away from the React Client. Execution away from the client means that no bundle needs to be sent for server components, and they will have access to the API environment where the React component code is executed. SSR implies an additional step where the output of that React component code is also turned into HTML on the server. In the context of server components, this means that the final HTML is produced on the server. In the context of client components, this means that an initial preview of HTML is created on the server, and that HTML is marked for hydration once it is sent to the client. For client components, javascript bundles are still sent such that hydration can result in the execution of code that has access to the browser API. Traditional CSR, not hydration, is only used on subsequent navigations and never for initial page loads.