ReactRSCNext.jsPerformance

React Server Components: A First Look

December 01, 2021

For the past decade, the trajectory of web development has been clearly defined: move more logic to the client. We transitioned from server-rendered PHP and Rails templates to thick-client Single Page Applications (SPAs). We sent large JSON payloads to the browser, hydrated the page, and let the client's CPU handle the routing, data fetching, and rendering. React Server Components (RSC) represent a paradigm shift that challenges this strictly client-centric world view, swinging the pendulum back towards a middle ground that attempts to combine the best of both worlds.

RSC allows us to move the backend logic into the component tree itself, without shipping that logic to the browser. It bridges the gap between the backend and the frontend in a way we haven't seen since the days of PHP, but with the component model we love.

Solving the Bundle Size Problem

In a traditional React app, if you want to format a date using a heavy library like moment.js or render markdown using remark, you have to ship the code for those libraries to the user's browser. This increases the Time to Interactive (TTI) and eats up the user's data plan.

With Server Components, this equation changes. "Server Components" run exclusively on the server. They render into a special JSON format that describes the UI, which is then streamed to the client. This means you can import massive dependencies, use them to generate the HTML, and zero bytes of that dependency code are sent to the client. The user gets the result, not the recipe.

Eliminating Network Waterfalls

A chronic issue in client-side React apps is the "network waterfall". A parent component loads, fetches data, and then renders a child. That child mounts, runs its own useEffect, fetches more data, and renders a grandchild. This sequential chain of requests results in a "popcorn" loading effect and sluggish performance.

Server Components execute on the server, where latency to the database is often negligible (single-digit milliseconds). The server can resolve all these nested data dependencies in a single pass and stream the fully formed UI tree to the client. This effectively moves the round-trips from the slow mobile network to the fast internal datacenter network.

Async Components & Data Fetching

Perhaps the most delightful change is the simplification of data fetching. We can say goodbye to the complexity of useEffect dependencies, loading states, and cleanup functions for basic data fetching. In RSC, a component can simply be an async function.

async function UserProfile({ userId }) 
  const user = await db.users.get(userId);
  return <div>{user.name}</div>;
}

This code looks synchronous, is easy to read, and runs entirely on the server.

The New Mental Model: Server vs. Client

This power comes with a new duality. Components are now either "Server" (the default) or "Client" (opt-in via the "use client" directive). Developers must now constantly evaluate the "execution context" of their code.

Need access to window, localStorage, or useState? Use a Client Component.
Need to fetch data from a DB or keep secrets? Use a Server Component.

The boundary is no longer the API call (fetch); it is the component prop. You can pass data from the server to the client component as props. This adds cognitive load but offers a level of optimization that was previously impossible. It empowers frontend developers to own the "Backend for Frontend" layer directly in their component tree.