Server Components vs Client Components

The plain-language idea

Every component you've met so far in this track eventually runs in the browser — even a server-rendered one is hydrated with its JS shipped down and re-executed client-side. React Server Components (RSC) are different: they render only on the server, output is sent as a description of UI (not HTML strings, not JS), and their code never ships to the browser at all.

// Server Component (default in a framework like Next.js's app router) — no directive needed
async function ProductList() {
  const products = await db.query("SELECT * FROM products");  // runs on the server, directly
  return <ul>{products.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;
}

// Client Component — opts in explicitly
"use client";
function AddToCartButton({ productId }) {
  const [loading, setLoading] = useState(false);   // needs interactivity -> must be client
  return <button onClick={() => addToCart(productId)}>Add to cart</button>;
}

ProductList can await a database call directly in the component — no API route, no useEffect, no loading state to manage, because it never runs on a device where "loading" is observable; the server just doesn't respond until it's ready. AddToCartButton needs useState and an onClick, which requires actually running in the browser, so it opts in with "use client".

Server Component: runs only on the server, ships zero JS to the browser, can await a database call directly.

BackNext

What people usually miss

Watch out

• This is not the same as "SSR." Traditional server-side rendering still ships every component's JS to the browser and hydrates it. Server Components' code genuinely never reaches the client bundle — smaller bundles, not just a faster first paint.
• A Server Component can render a Client Component, but not vice versa (directly) — a Client Component can only receive already-rendered Server Component output via children/props, it can't import and render one itself, since a Server Component might do things (query a database) that make no sense to run in the browser.
• Server Components can't use hooks or browser APIs — no useState, useEffect, onClick; anything needing interactivity has to live in (or below) a "use client" boundary.

Why this matters in interviews

This is one of the more current React topics to come up at senior interviews specifically because it changes real architecture decisions — knowing where to draw the client/server boundary in a component tree, not just that the feature exists, is the actual signal.