The RSC model: two environments, one tree

Two environments, one tree

A React tree in an RSC framework spans two environments. Server components — the default, no directive needed — execute on the server, once per request (or once per revalidation, if the framework caches). They can be async functions: await db.query(...), read the filesystem, call an internal service — data access with no API endpoint in between. Because they run to completion and are then gone, they cannot hold useState, schedule useEffect, attach event handlers, or touch window — there is no “later” for them in any browser. Client components — modules that start with the 'use client' directive — are bundled, downloaded, hydrated, and then live: state, effects, handlers, browser APIs. One tree freely interleaves both kinds: a server page renders a client RangePicker, which can itself receive server-rendered children (that interleaving is the next lesson).

One naming trap is worth killing early: “server component” does not mean “renders on the server” — SSR has been rendering client components on the server for a decade. It means only ever exists on the server. The component’s code is never part of any bundle, and it never re-executes in the browser.

What the server half of the tree buys you

Three concrete wins, in descending order of how often they justify the migration:

• Zero bundle weight for server-only code. A syntax highlighter with its grammars and themes runs to hundreds of kB even minified; a markdown parser plus sanitizer adds tens more; a date/i18n stack with locale data the same again. In a server component those imports cost the client nothing — the docs platform in the Hook cut ~900 kB this way without deleting a feature. The user downloads the output of those libraries, never the libraries.
• Direct data access. The query lives next to the component that needs it, runs at datacenter latency (sub-millisecond to single-digit ms to the database, versus 50–300 ms RTT from a browser), and never exposes an API surface you must version and secure separately.
• Automatic code splitting. Every 'use client' boundary is a split point: client components arrive as separate chunks referenced from the payload, loaded when the tree actually mounts them. Nobody maintains React.lazy bookkeeping by hand.

Together, these three properties mean the server half of your tree pays for itself: heavy libraries never hit the client, data fetching moves to where it is cheapest, and bundle splitting becomes structural rather than a manual chore. Skip the server-component model entirely and you trade all three back for a simpler mental model — a real tradeoff, not a free lunch.

The Flight payload: a tree with holes, not HTML

When a request comes in, server components execute and dissolve into their output. What goes over the wire is the RSC payload (the format React calls Flight): a serialized element tree, not markup. Shape simplified:

0:["$","article",null,{"children":[
  ["$","h1",null,{"children":"Q3 traffic report"}],
  ["$","$L1",null,{"initialRange":"30d","points":[120,84,97]}]]}]
1:I["./RangePicker.js",["chunk-1f9a"],"RangePicker"]

Row 0 is the already-resolved markup that server components produced — plain elements, their work done. $L1 is a hole: a module reference where a client component mounts. Row 1 resolves it — which chunk to download, which export to use — and the props sitting in the hole (initialRange, points) were serialized server-side, which is why they must be serializable at all. Notice what is absent: the server components themselves, their data-fetching code, the markdown parser. They contributed output, not code. The payload streams, too — rows arrive incrementally, so a slow query deep in the tree does not block the rows above it.

RSC and SSR are different layers — and they compose

This is the distinction interviews keep probing because production teams keep blurring it. SSR takes client components and renders them to HTML once on the server, so the user sees pixels before the bundle loads; the code still ships, hydration still runs, and from then on the component lives in the browser. SSR is a first-paint optimization for client React. RSC is a persistent server layer: server components re-render on the server whenever the client navigates or refetches, and their code never ships at all.

They compose rather than compete. First load: server components run → Flight payload → the SSR pass renders the whole tree (client components included) to HTML → the browser paints immediately → hydration brings only the client components to life, using the inlined payload as the tree description. Navigation afterwards: no HTML at all — the client fetches a fresh Flight payload for the new route and React reconciles it into the live DOM, preserving the state of client components that stayed in place. HTML appears exactly once in this pipeline, and only as a first-paint artifact.

Failure mode: where did onClick go

The Copy-button incident generalizes. onClick={copy} on a button inside a server component means a function has to cross into the payload — and functions do not serialize (what would the browser receive — the source? its closure? its database handle?). Frameworks fail fast in dev: “Event handlers cannot be passed to Client Component props.” The fix is never to mark the whole page 'use client' — that drags every import on the page back into the bundle and undoes the migration. Extract the smallest interactive leaf (CopyButton.tsx, ten lines, 'use client' at the top) and keep the article itself on the server. The review smell to watch for: a 'use client' at the top of a 400-line page file, added to make one button work.