How React Works (Part 8)? Server Components & Hydration: The Real Story

Server Components & Hydration: The Real Story

Series: How React Works Under the Hood
Part 1: Motivation Behind React Fiber: Time Slicing & Suspense
Part 2: Why React Had to Build Its Own Execution Engine
Part 3: How React Finds What Actually Changed
Part 4: The Idea That Makes Suspense Possible
Part 5: The React Lifecycle From the Inside
Part 6: How State Actually Works
Part 7: The Trap of Vibe Coding useCallback
Prerequisites: Read Parts 1–7 first.

Where We Left Off

Through Parts 1–7, every problem we solved lived on the client. The call stack couldn't pause — so React built Fiber. Re-rendering was too slow — so React built the Reconciler. State management was confusing — because it's a queue on a Fiber node, not a variable. Performance tools were overused — because developers reached for them before understanding the problem.

Every solution stayed inside the browser. The user's device was the bottleneck. The network was just the delivery mechanism.

Part 8 changes that. Because there's a whole category of problem that no client-side optimization can fix — and it took the React team until 2023 to fully solve it.

The Problem Nobody Talks About

You've shipped a React app. You've done everything right. You memoized where it mattered. You fixed re-renders. You code-split your routes. React DevTools shows a clean profile. Your API is fast.

Then you open Chrome on a mid-range Android phone with a throttled 3G connection — the kind of device hundreds of millions of people actually use — and you watch the screen stay white for four seconds before anything appears.

You look at the Network tab. Before your user sees a single pixel of your app, their phone downloaded, parsed, and executed 380kb of JavaScript. You open the bundle analyzer. Half of that JavaScript is components that render completely static content — a product description that never changes, a nav with hardcoded links, a footer, a terms page. None of them use state. None of them handle events. They just render text and markup.

But they ship to every client. On every load. On every device. Including that phone on 3G that Part 1 opened with.

This is the problem that Part 1's question — "with vast differences in computing power and network speed, how do we deliver the best user experience for everyone?" — still hadn't fully answered by the end of Part 7. We optimized what happens on the client. But we never questioned why so much work was happening on the client in the first place.

The naive fix was server-side rendering. But SSR had a fundamental flaw that took years to properly name — and understanding that flaw is what makes Server Components make sense.

The Problem: The Two-Trip Lie

To understand why Server Components exist, you need to go back to how server rendering worked before them.

Dan Abramov explained the origin story in his RSC from Scratch deep dive by taking you back to 2003. PHP on a server: the server gets a request, reads a file or a database, returns HTML. Simple. The user sees content immediately. No JavaScript bundle to download. No client-side rendering. Just a server doing work and returning a result.

React brought rich interactivity but also a cost: everything runs in the browser. Large bundles. Slow initial loads on slow connections. So the industry added server rendering back — render HTML on the server first, send it to the client, then download JavaScript and "hydrate" the page to make it interactive.

This solved the blank screen problem. But it created what the React team calls a two-trip problem.

The server renders HTML — fast, visible immediately. Then the browser downloads all the JavaScript anyway. React runs again on the client. Re-does the work. Attaches event listeners. Any data fetched on the server to render the HTML? Fetched again on the client. Bundle size? Unchanged — every component that ran on the server also ships to the client. Server work didn't reduce client work. It looked like a performance win but the full cost came later.

This is the problem Server Components actually solve.

What Hydration Actually Is — and What's Wrong With It

Server-side rendering gave React apps faster first paint. But it introduced a problem that almost nobody explained clearly: the page looks ready before it is.

The server renders HTML and sends it. The user sees a complete-looking page — the nav, the content, the buttons. They try to click something. Nothing happens. The button doesn't respond. The form doesn't submit. The dropdown doesn't open. The page looks interactive but it isn't — because React hasn't attached any event listeners yet.

This is the hydration gap. And it exists because of how hydration works.

From jser.dev's hydration internals: hydration is not re-rendering. React does not recreate the DOM. Instead, React walks the existing server-rendered DOM tree in parallel with the Fiber tree it's building, matching each fiber to its corresponding DOM node — storing a reference in fiber.stateNode. Event listeners are attached. The DOM is reused. This is why hydration is faster than a fresh render.

But the entire tree must hydrate before any part becomes interactive. One slow component at the top of the tree blocks the click handlers on a button at the bottom. React walks the tree sequentially, and until that walk is complete, nothing responds.

React 18 fixed this with selective hydration. Using the same Lanes priority system from Part 3, React can now interrupt hydration to handle a user interaction first. If a user clicks a button before hydration reaches it, React jumps to that boundary using SyncLane — hydrates just enough to handle the interaction — then resumes the rest of the tree. The architecture from Part 3 extends directly here: interruptible work, priority-driven, same system.

Streaming takes this further still. Instead of waiting for all data before sending any HTML, the server sends the shell immediately and streams each Suspense boundary as its data resolves. The client starts hydrating what arrived while the rest is still coming. Multiple chunks, progressive — no blank screen waiting for the slowest database query.

But even with selective hydration and streaming, there's still a cost that SSR never eliminated. The JavaScript still ships. Every component still runs on the client. That's the problem Server Components solve.

What Server Components Actually Are

From the React Labs March 2023 blog post, written by the React team:

"We are introducing a new kind of component — Server Components — that run ahead of time and are excluded from your JavaScript bundle. Server Components can run during the build, letting you read from the filesystem or fetch static content. They can also run on the server, letting you access your data layer without having to build an API."

Server Components run only on the server. Their code never ships to the client. Client Components — marked explicitly with 'use client' — run on the client as before. The boundary between them is a decision you make explicitly at every component.

The critical constraint the boundary enforces: functions cannot cross from Server to Client. Functions aren't serializable. If you try to pass a function as a prop from a Server Component to a Client Component, React throws an error. Only plain serializable values can cross — strings, numbers, objects, arrays, React elements. This shapes every RSC architecture decision. It's why you can't pass event handlers from the server side.

What the server sends is not HTML and not JavaScript. It's the RSC payload — a JSON-like description of the rendered UI tree. Here's what a simple RSC payload actually looks like in practice:

J0:["$","div",null,{"className":"post"}]
J1:["$","h1",null,{"children":"Hello World"}]
J2:["$","p",null,{"children":"Content here"}]

Each line is a serialized React element — type, key, ref, props. React on the client reads this and builds or updates its Fiber tree from it. As Dan's RSC from Scratch describes: "a production-ready RSC setup sends JSX chunks as they're being produced instead of a single large blob at the end. When React loads, hydration can start immediately — React starts traversing the tree using the JSX chunks that are already available."

For Client Components, only their props get serialized into the payload — not their code, which stays in the bundle. The payload contains a reference to the Client Component (a module ID the bundler knows about) plus the props to render it with.

This is why RSC works with client-side navigation: navigating to a new page in a Next.js App Router app doesn't reload the whole page. It fetches a new RSC payload and React merges it into the existing Fiber tree — same mechanism, different data.

The React docs explain this model clearly — the boundary rules, how composition works, how to think about what goes where. It's genuinely good documentation.

What the docs didn't prepare developers for: the mental model they encourage — writing async function submitOrder() marked 'use server' and calling it like any local function — is exactly the mental model that skips the input validation you'd never skip on an API route. In December 2025, that gap cost real companies their servers.

The Security Reality: React2Shell

On November 29th, 2025, security researcher Lachlan Davidson reported a vulnerability to Meta's Bug Bounty program. Four days later, the React team disclosed it publicly.

From the official React blog post:

"There is an unauthenticated remote code execution vulnerability in React Server Components."

CVE-2025-55182 — CVSS 10.0.

The root cause: React Server Functions (Server Actions) allow a client to call a function on the server. React translates the client's request into an HTTP request, which the server deserializes and executes. The deserialization process did not properly validate inputs. An attacker could craft a malicious HTTP request that, when deserialized by React, achieved remote code execution on the server — with no authentication required, against any app using React Server Components.

The React blog was direct: "Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components."

Exploits appeared within 24 hours of disclosure. Unit 42 at Palo Alto Networks documented post-exploitation activity including reverse shells, malware installation, and activity linked to state-sponsored threat actors.

Two follow-on CVEs were disclosed days later: source code exposure (CVE-2025-55183 — a crafted request could cause the server to return its own source code) and denial of service (CVE-2025-55184 — a crafted request caused an infinite loop that hung the server process permanently). The initial fix for the DoS was incomplete, requiring a second patch under CVE-2025-67779. A fourth vulnerability was disclosed in January 2026 (CVE-2026-23864).

What this means for you as a developer:

Every Server Action ('use server' function) is a public HTTP endpoint. Anyone on the internet can send a POST request to it — not just your frontend. There is no framework magic that makes inputs safe by default. You must validate and sanitize every argument exactly as you would validate input to an Express route handler or an API endpoint.

The mistake RSC encourages is writing server-side logic that feels like an internal function — you're just calling submitForm() from a button click, it looks local. But it's an HTTP endpoint. Untrusted input. Treat it that way.

Additionally: whatever you pass as props from a Server Component to a Client Component travels in the RSC payload — visible in the browser's network tab. Pass only what the client needs to render. Passing an entire database row when only a name is needed exposes the rest of that data to anyone watching the network response.

A Concrete Trace: What Actually Happens on Navigation

Let's make this real. When a user clicks a link in a Next.js App Router app:

User clicks a link. React intercepts the navigation. Instead of a full page reload, it fetches the RSC payload for the new route from the server.

Server processes the request. Server Components for the new route run — async, querying databases, reading files. They render to the RSC payload format. Client Component boundaries are replaced with module references plus serialized props.

Payload streams to the client. The response arrives in chunks. React starts processing chunks as they arrive — it doesn't wait for the complete response.

React merges the payload into the Fiber tree. For unchanged parts (shared layout, nav), React skips re-rendering entirely. For new content, React creates or updates fibers from the payload. Client Components receive their serialized props and render on the client.

The page updates. No full reload. No loss of client-side state. The URL changes. The content changes. Client Components that were already hydrated stay hydrated.

This is the genuine architectural win: the server does the data work, the client does the interaction work, and the payload is the bridge between them.

The Vibe Coding RSC Trap

In Part 7 we saw what happens when developers add useCallback and React.memo everywhere without measuring — code that's harder to read, harder to debug, and often slower than before.

The same pattern exists with Server Components. You read the Next.js App Router docs. You migrate your pages directory. You follow the examples. And you end up writing code like this:

// Every component that uses state or events gets 'use client'
'use client';
export function Header() { ... }

'use client';
export function SearchInput() { ... }

'use client';
export function ProductCard() { ... }

'use client';
export function Footer() { ... } // doesn't even use state — added just in case

Every component is a Client Component. Every component ships JavaScript to the client. The RSC architecture is in place — the routing, the layout, the page files — but the actual benefit (JavaScript that never ships) is zero. You've added the complexity of the Server/Client boundary, the mental overhead of 'use client' everywhere, and the security surface of Server Actions — for a bundle size identical to before.

This happens because the docs show you the mechanics but not the principle. The principle is simple: a component should only be a Client Component if it genuinely needs the client — state, effects, browser APIs, event handlers. Everything else can be a Server Component. A product description that just renders text? Server Component. A nav with static links? Server Component. A footer? Server Component. The question to ask for every component is: does this need to run in the browser?

The vibe coding version asks: does the tutorial mark this as 'use client'? If yes, add it. If the app breaks, add more. This produces an RSC app that costs more than the original — in complexity, in security surface, in developer confusion — and delivers nothing.

When You Don't Need Server Components

Dan Abramov and Joe Savona discussed the honest tradeoffs of RSC in their live stream with Kent C. Dodds. The team has never claimed RSC is the right tool for every app.

If your app is mostly interactive — drawing tools, real-time editors, complex forms — it consists almost entirely of Client Components anyway. RSC adds architectural complexity for minimal gain. If your API and frontend run in the same region, the round-trip savings from server-side fetching are negligible. The complexity isn't justified by the performance return.

The more important consideration is team understanding. The React2Shell vulnerability was possible because the boundary between trusted server code and untrusted client input was blurry in the mental model. A team that treats Server Actions as internal functions will skip input validation — and that's not a performance problem, it's a critical security bug.

And if you're adopting RSC because it's what the new Next.js docs show, stop and ask what problem you're solving. The React Labs blog post frames RSC as combining the simple request/response model of multi-page apps with the interactivity of single-page apps. That's a genuine win for content-heavy apps with complex data requirements. For a CRUD app with a fast API and a small bundle, you may be adding architectural weight to solve a problem you don't have.

Measure the actual loading problem first. Understand the tradeoff. Then decide.

The One-Sentence Rule

Use Server Components when you have a measured loading problem caused by JavaScript bundle size or data waterfalls — and your team treats every Server Action as a public HTTP endpoint that requires the same validation discipline as any API route. In every other case, measure the problem first.

What's Coming in Part 9

Part 9 is the last article in the series. It answers the question Part 1 opened with: "With vast differences in computing power and network speed, how do we deliver the best user experience for everyone?" — pulling every piece of the series together into one complete picture.

🎬 Watch These

Dan Abramov — RSC from Scratch (GitHub Discussion)
The canonical technical deep dive — inventing RSC from first principles. The RSC payload format and the streaming architecture described in this article come directly from this document.

Dan Abramov + Joe Savona — RSC Live Stream with Kent C. Dodds
Honest discussion of RSC tradeoffs, limitations, and the mental model shift required. The source for the "when you don't need RSC" framing.

JSer (jser.dev) — How basic hydration works internally in React?
The tryToClaimNextHydratableInstance, fiber.stateNode matching, and cursor-based DOM walking described in this article.

JSer (jser.dev) — What is Progressive Hydration and how does it work internally?
Streaming HTML in chunks, Suspense comment node markers (<!--$-->, <!--$!-->), and the retry callback mechanism.

🙏 Sources & Thanks

• Dan Abramov — RSC from Scratch (Part 1) written by @gaearon on the reactwg GitHub. The PHP origin story, the RSC payload format, the streaming architecture, and the quote about JSX chunks all come directly from this document.

• The React Team — React Labs: March 2023 — the official Server Components definition quoted directly. Critical Security Vulnerability in React Server Components — the official React2Shell disclosure, the vulnerability overview, and the timeline all come from the react.dev blog post.

• Lachlan Davidson — for discovering and responsibly reporting CVE-2025-55182 to Meta's Bug Bounty program.

• jser.dev — the hydration mechanics (tryToClaimNextHydratableInstance, nextHydratableInstance cursor, fiber-to-DOM matching, selective hydration with Lanes priority, streaming with comment node markers) all come from JSer's source-level analysis: How basic hydration works, How hydration works with Suspense, What is Progressive Hydration, and My guess at how RSC works.

• Unit 42 / Palo Alto Networks — for the post-exploitation analysis of CVE-2025-55182 documenting real-world attack patterns.

• Dan Abramov + Joe Savona — RSC Live Stream with Kent C. Dodds — for the honest discussion of RSC tradeoffs that informed the "when you don't need it" section.

Part 9 is the final article — the full picture, from Part 1's question to the complete answer. 🔧

Tags: #react #javascript #webdev #tutorial #security