RSC Is Not SSR. I Know, I'm Sorry.

See the pattern? The server components form most of the tree. They handle data fetching, rendering, and layout. The client components — LikeButton and CommentForm — are just the small interactive islands that genuinely need browser APIs.

The "use client" directive is not what you think it is

Most people read "use client" and think it's a label that marks a component as "this runs on the client." It's not. It's a module system boundary.

What it actually says is: everything in this file, and everything this file imports, is the client boundary. React will bundle all of it and ship it to the browser. Once you cross the boundary by importing from a "use client" file, you're in client territory.

// LikeButton.tsx
'use client';  // ← This is a module boundary, not a component property

// Everything below this line runs on the client.
// Everything this file imports also runs on the client.

import { useState } from 'react';
import { motion } from 'framer-motion'; // ← also gets bundled

export function LikeButton({ articleId, initialCount }) {
  const [count, setCount] = useState(initialCount);
  // ...
}

The implication: be careful what you import inside "use client" files. If you accidentally import a large library inside a client component, it ends up in the browser bundle. The goal is to keep client components small and focused.

Composition across the boundary

There's a pattern that confuses a lot of people: you cannot import a server component inside a client component. But you can pass server components as props to client components — specifically as children.

// ✗ This doesn't work — you can't import a server
// component inside a client component
'use client';
import { ServerSideWidget } from './ServerSideWidget'; // ✗

// ✓ This works — pass server components as children
// from a parent server component

// ParentServer.tsx (server component)
import { ClientShell } from './ClientShell';
import { ServerSideWidget } from './ServerSideWidget';

export function ParentServer() {
  return (
    <ClientShell>
      <ServerSideWidget /> {/* ← server component passed as children */}
    </ClientShell>
  );
}

// ClientShell.tsx
'use client';
export function ClientShell({ children }) {
  const [open, setOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setOpen(!open)}>Toggle</button>
      {open && children} {/* ← server component renders here */}
    </div>
  );
}

The reason this works: the server component is rendered on the server before it's passed as children. By the time the client component receives it, it's already a serialized React tree — not executable code. The client component never needs to import or run the server component.

What React actually sends to the browser

This is the part that almost no one talks about, and I think it's the most useful thing to understand. The RSC payload format is genuinely different from anything React did before. Let's look at it.

Look at the RSC Wire Format tab. The key thing to notice: the server component code (ArticleCard) is gone. What's left is just the rendered output — the serialized React tree. The ArticleCard function itself never reaches the browser.

LikeButton is there, but only as a reference ($L1) pointing to a module (M1). React knows to load that JavaScript chunk and insert the client component at the right place in the tree.

RSC + Suspense = streaming

One more thing worth knowing: RSC and Suspense work together to enable streaming. Instead of waiting for every server component to finish fetching before sending anything, React can start streaming the tree to the browser as each component resolves.

// page.tsx (server component)
import { Suspense } from 'react';

export default function Page() {
  return (
    <div>
      <Header /> {/* ← renders immediately, no data needed */}
      <Suspense fallback={<ArticleSkeleton />}>
        <ArticleContent /> {/* ← streams in when ready */}
      </Suspense>
      <Suspense fallback={<CommentsSkeleton />}>
        <CommentsSection /> {/* ← streams in independently */}
      </Suspense>
    </div>
  );
}

The header renders immediately. The article and comments stream in as their data becomes available — independently of each other. No artificial loading hierarchy, no "wait for everything before showing anything."

What can and can't a server component do?

Quick summary, because people ask:

The mental model shift

Here's the reframe that helped me internalize RSC: instead of thinking "which components run on the server?" — think "which components genuinely need to run in a browser?"

In most apps, the answer to the second question is: not many. State management, event handlers, browser animations, form inputs — those components need to be client components. But a lot of what we write is just data fetching + rendering. That doesn't need a browser.

By default in Next.js App Router, all components are server components. You opt into client behavior with "use client". That inversion from what we were used to is what confuses people, but once it clicks, it makes a lot of sense.