00 Explorable explanation · the missing piece, made mechanical

One <Counter/> becomes a registered reference, a manifest row, a Flight tuple, a required module — and only then a live, clickable button.

"React records a reference" is not the explanation — it is the part that still needs explaining. The real bridge is a chain of concrete artifacts: a "use client" source file becomes a build-time client reference proxy, recorded in a client reference manifest; during the RSC render React Flight resolves that reference into module metadata — a module id, chunk filenames, and an export name; the metadata rides the RSC payload to the browser, where the Flight client decoder preloads the chunk, calls __webpack_require__ by id, reads the export, and hydrates the DOM the browser already painted. Press play and ride the whole line, station by station.

01 Two related server-side products

The server does two things, not one

App Router rendering splits into two related server-side products from a single render. React renders Server Components into the RSC / Flight payload; then Next uses that payload plus Client Component JavaScript instructions to render HTML. On the client, the HTML is the immediate preview, the RSC payload reconciles the server and client trees, and JavaScript hydrates the Client Components. Press play to watch one render fan out into both.

02 The correct mental model

"use client" marks a module boundary, not a visual subtree

The phrase "use client" does not first mark a region of the screen. It introduces a server–client boundary in the module dependency tree and creates a subtree of client modules. During render the framework server-renders the root and walks the render tree, opting out of evaluating any code imported from client-marked code. Press play to peel the one render tree apart into two module graphs.

// stays on the server
app/page.tsx
  ├─ db queries
  ├─ server-only utilities
  ├─ layout.tsx
  └─ non-"use client" components

// crosses to the browser
app/Counter.tsx   "use client"
  ├─ react useState
  ├─ browser event handlers
  └─ modules imported by Counter.tsx

03 The signature idea

Counter has three identities at once

This is the whole bridge in one frame. The symbol you wrote — <Counter/> — exists as three different things, and the manifest plus Flight metadata are the threads that connect them. Press play to watch each identity appear.

04 The simple case, made precise

A Server Component can produce HTML without ever shipping JS

"Server Components don't run in the browser" does not mean "Server Components don't produce HTML." It means the browser sees their output, not their implementation. With no client boundary in sight, the pipeline is short — and nothing about Page is ever sent to the browser.

export default function Page() {
  return (
    <main>
      <h1>Hello from the server</h1>
      <p>This is a Server Component.</p>
    </main>
  )
}

<!-- result, not implementation -->
<main>
  <h1>Hello from the server</h1>
  <p>This is a Server Component.</p>
</main>

// no Page.js · no hydration · 0 KB

05 The demystification layer · build time

Build time writes a proxy and a manifest

When a Server Component imports a Client Component, the build does not use the original client implementation as ordinary server code. The next-flight-loader emits a registered reference, and a manifest plugin records where the real module lives. Press play to watch app/Counter.tsx become both.

import { registerClientReference } from "react-server-dom-webpack/server"

export default registerClientReference(
  function () {
    throw new Error("Attempted to call the default export from the server...")
  },
  "/app/Counter.tsx",   // resource key
  "default"             // export name
)

type ClientReferenceManifestEntry = {
  id: string | number     // e.g. 4872
  name: string             // e.g. "default" / "*"
  chunks: Array<string>    // chunk ids + filenames
  async?: boolean
}

06 The demystification layer · server render

The render turns a reference into a loading tuple

When React Flight serializes a client reference, it must turn /app/Counter.tsx + default into concrete loading metadata: a module id, chunk files, an export name, and an async marker. React's server-side webpack Flight config has resolveClientReferenceMetadata — it takes the manifest plus the reference, looks up the reference's $$id, and returns [id, chunks, name]. Press play to follow the lookup.

// the resolved Flight metadata for Counter
[ 4872, ["123", "static/chunks/app/counter-abc123.js"], "default" ]

// async modules carry a 4th element:
[ 4872, [ …chunks… ], "default", 1 ]

07 The demystification layer · browser

The browser decodes the tuple and loads the real module

On the browser side, React's Flight client receives metadata for a client reference. It can use the already-resolved metadata directly: resolveClientReference returns [id, chunks, name], preloadModule loads the chunks, and requireModule calls __webpack_require__(metadata[ID]) before returning the requested export. The client never inspects the DOM and never reads the manifest file — it acts on metadata that arrived in the stream. Press play.

// Flight says
module id: 4872
chunks: ["123", "static/chunks/app/counter-abc123.js"]
export: "default"

// React Flight client
preloadModule(metadata)
  → loadChunk("123", "static/chunks/app/counter-abc123.js")
requireModule(metadata)
  → __webpack_require__(4872)
  → moduleExports["default"]
  → the actual Counter function

08 The transport, in one minute

self.__next_f.push(...) is the courier

On initial load the browser gets one text/html response, and Next embeds the Flight data as inline scripts. The first push seeds a bootstrap segment into self.__next_f; later chunks push Flight data. The array buffers segments until Next's app runtime loads, drains the backlog, and patches .push so future chunks pipe straight into the Flight reader. The metadata tuple from the last section rides inside these chunks — the array carries it, React's decoder resolves it.

zoom in · what actually rides inside one chunk

09 The cast of the bridge

Every piece, and the one job it does

The bridge is not one mechanism — it is a relay of small, boring, specific artifacts, each with a single responsibility. Tap a card to see what it is, why it matters, and how it looks under the hood.

10 What the bridge is not

Common confusions, corrected

Most misunderstandings of RSC come from collapsing two of the three identities, or from imagining the browser does something clever it never does. Tap each to see the correction.

11 The shortest correct version

The whole bridge, in one paragraph