The Two Component Worlds

"The client and server environments have different capabilities. Server and Client components allow you to run logic in each environment depending on your use case." — Next.js Documentation, "Server and Client Components"

For about a decade, a React component was one kind of thing. It was a function that took props and returned elements, it ran in a browser, and if you were doing server-side rendering it also ran on a server — but it was the same function running twice, and the whole discipline of SSR was arranging for those two runs to agree. Everything you knew about components applied uniformly, because there was only one kind.

There are now two. They are both written as functions that take props and return elements, they live in files that look identical, and they can render each other. But they run in different places, at different times, with different capabilities, and — this is the part that takes longest to internalise — only one of them ever reaches the browser at all. A server component is not a component that runs on the server first and the client later. It is a component that runs on the server and then ceases to exist, leaving behind only its output.

That single fact reorganises everything. It is why a server component can hold a database password and a client component cannot. It is why a server component can be async and a client component cannot. It is why you can pass a number across the boundary but not a function. It is why moving 'use client' up one file can add two hundred kilobytes to your bundle, and why the fix is usually to move it down rather than to remove it.

This chapter establishes the division itself: what each world can do, what a server component actually turns into, what the browser receives on a first load versus a navigation, and what all of that costs. The next chapter takes the boundary between them and works out exactly where it falls, which is a subtler question than it looks. For now the goal is to stop thinking of "server component" as "component, rendered on the server" and start thinking of it as a different kind of thing entirely — one whose output is data, not markup, and whose code the user never receives.

Two environments, two capability sets

Start with the capabilities, because most placement decisions follow mechanically from them. The rule is not stylistic. A component belongs in the client world if and only if it needs something that only exists in a browser; otherwise it stays where it starts, which is on the server.

The last row deserves its own emphasis, because it is where most real confusion lives. People hit a component that queries a database and has a filter input, conclude that the model does not fit their application, and mark the whole thing 'use client' — at which point the database call has to move somewhere else anyway, and they have shipped the rest of the component to the browser for nothing. The model does fit. It is telling you the component had two responsibilities.

One capability difference is worth calling out separately because it produces a confusing error rather than a design question. A client component cannot be async. Server components can be, and it is one of their headline features — const post = await getPost(id) directly in the component body. Client components cannot, because React needs to be able to re-render them synchronously at any time. When a client component needs to read something asynchronous, including the params promise from chapter two, it uses React's use() hook rather than await.

What a server component actually becomes

Here is the piece that fixes the mental model. A server component does not render to HTML and stop. It renders to the RSC payload — a compact serialised representation of the rendered tree — and the documentation is precise about what that payload contains. Three things:

1. The rendered result of the server components.
2. Placeholders for where client components go, plus references to their JavaScript files.
3. Any props passed from a server component to a client component.

Modelling that structure is the fastest way to understand every rule that follows.

Read the payload as a list and the rules stop needing to be memorised. Client components appear as references — a name and a URL to a JavaScript chunk — which is why marking a component 'use client' adds weight: you have added a chunk the browser must fetch. Props appear as literal values inside the payload, which is why they must be serialisable, and which is the subject of the third chapter of this part. And server component code appears nowhere at all, which is why it is both free and safe.

That last point has a corollary people find surprising: a heavy dependency used only in a server component costs the browser nothing. A date-formatting library, a Markdown parser, a syntax highlighter — if the only thing that reaches the client is the formatted string, the library never ships. The same import inside a client component ships in full.

First load and every load after it

The two paths through the system are different, and the difference explains a whole family of bugs — including the reason a component can render correctly on refresh and wrongly on navigation.

On a first load, three things arrive and are used in order. HTML gives an immediate non-interactive preview. The RSC payload reconciles the client and server trees. JavaScript hydrates the client components and makes them interactive. On a subsequent navigation, the HTML step is gone entirely: the RSC payload is fetched (usually already prefetched, per Part I), and client components render on the client with no server-rendered HTML at all.

That asymmetry is the seed of the hydration chapter at the end of this part, and it is worth carrying from here: hydration mismatches are a first-load phenomenon. A component reading localStorage during render is broken, but it is only visibly broken when someone reloads the page — which, exactly as with the navigation timings in Part I, is not the path you naturally test.

What it costs, and where the boundary should sit

Now the practical consequence. Because 'use client' marks a file and everything reachable from it, the position of the directive decides the size of the bundle. The documented advice — add the directive to specific interactive components rather than to large parts of the UI — is easy to nod along to and easy to violate, because the violating version is the one that requires less thought.

Sixty-six kilobytes for a search box versus one hundred and five for the same search box plus three components that never change. The difference is not an optimisation you apply later; it is a consequence of which file the directive is in, and it compounds, because every future import into that layout is now also a client import.

There is a related trap in the same shape. Marking a component 'use client' and then importing a heavy library into it is a decision most people would review carefully. Importing that library into a file that is already on the client side of the boundary is the same decision, and it does not look like one — nothing in the diff says 'use client', and the weight arrives silently.

Keeping server code on the server

The last piece is a safety property, and it is more subtle than "server components are private". Modules can be imported by either world, so a helper written for the server can be pulled into a client component by an ordinary import that no reviewer will look at twice.

Next.js gives you two lines of defence, and it is worth knowing exactly what each one does — because one of them is a build-time error and the other is a silent substitution.

The pairing is deliberate. NEXT_PUBLIC_ substitution protects your users; server-only protects your afternoon. Both packages — server-only and its counterpart client-only — are optional installs in Next.js, which handles the imports internally to produce clearer errors; the npm packages' actual contents are not used.

Common Mistakes

1. Thinking a server component runs on the server and then again on the client. It does not. It runs once, on the server, and only its output travels. That single misconception generates most of the confusion in this part of the book.

2. Marking a whole layout or provider 'use client' because one leaf inside it needs state. The directive covers the file and everything reachable from it, so the bundle grows by far more than the interactive part.

3. Treating "needs a database and needs state" as an unsupported case. It is a component with two responsibilities. Split it: server component fetches, client component interacts.

4. Making a client component async. Only server components can be. A client component reads promises with React's use() instead.

5. Assuming a heavy dependency is expensive wherever it is used. In a server component it costs the browser nothing, because the code never ships. The same import in a client component ships in full.

6. Testing only by navigating. Client components render twice on a first load and once on a navigation, so anything that renders differently on the server than in the browser breaks only on refresh.

7. Relying on NEXT_PUBLIC_ stripping as your protection. It prevents the leak but converts the mistake into a confusing runtime failure elsewhere. Add server-only so the build stops at the import.

8. Prefixing a genuine secret with NEXT_PUBLIC_ to silence a problem. That is the one action that actually publishes it — the prefix is a declaration that the value is public.

9. Rendering context providers at the root of the document. Wrap {children} and push the provider as deep as it will go, so the static parts of the tree above it stay server-rendered.

10. Adding an import to an existing client file without noticing it is a client file. No directive appears in the diff, and the weight arrives silently. The boundary is a property of the file, not of the line you are editing.

Interview Corner

Summary

• Server Components are the default. Nothing is a Client Component until a file says 'use client', so the question is always "does this need to leave the server", never "should this be a Server Component".

• A Server Component runs once, on the server, and its code never reaches the browser. It is not the same function running in two places.

• The RSC payload contains three things: the rendered server output, placeholders and chunk references for Client Components, and the props that crossed the boundary.

• Server Component code and its dependencies weigh nothing on the client, which is why a heavy library used only there is free — and why the same import in a Client Component is not.

• Secrets cannot leak through the payload, because only computed values are in it, not the code that computed them.

• A first load renders Client Components twice — once on the server for the HTML preview, once in the browser to hydrate — while a navigation renders them once, in the browser only.

• Hydration mismatches are therefore a first-load phenomenon, invisible to testing that only clicks between pages.

• A Client Component cannot be async. It reads promises with React's use() instead.

• 'use client' covers the file and everything reachable from it, so its position decides the bundle size. Push it toward the leaves; render providers deep, wrapping {children}.

• NEXT_PUBLIC_ stripping prevents the leak; server-only prevents the mistake. The first fails confusingly at runtime, the second fails clearly at build time.

We now know there are two worlds and roughly where things belong. What we have not pinned down is exactly where the line falls — and it is not simply "files with the directive". The next chapter, The 'use client' Boundary, works out what the directive marks, why a Server Component passed as children to a Client Component stays on the server, and why the module graph rather than the render tree is what decides.