React Server Components
The problem
Fetching data in a client component means shipping a component's code to the browser, running it, then waiting on a network request before anything useful renders — for content that never needs interactivity, that round trip and the extra JavaScript sent to the client are pure overhead the server could have avoided by rendering the final result once, upfront.
Why now
Suspense already gave React a way to pause rendering while waiting on data; Server Components take that further by moving certain components' entire execution to the server, where they can talk directly to a database or file system — the same request/response model building-an-http-server already covers, but now producing a rendered UI description instead of JSON.
Mental model
A Server Component runs only on the server, once, during the request — it can read a database directly and never ships its own code to the browser, only its rendered output. A Client Component is the traditional React component, hydrated and interactive in the browser. Splitting a tree between the two means only the interactive parts pay the JavaScript-bundle and hydration cost, while purely presentational, data-fetching parts render once on the server and send nothing but their result.
Requires
- Concurrent Rendering & SuspenseReact
Server Components stream their rendered output to the client using the same Suspense-based mechanism already covered — a Server Component's data fetch suspends exactly like a client-side one, just with the actual work happening server-side.
- Building an HTTP ServerBackend Engineering
Server Components execute within a server's request/response cycle, reading data directly the way any server-side code would; you need that request-handling model already understood before 'a component that runs on the server' is a coherent idea rather than a contradiction.
Used in
- Next.js's App Router, built around Server Components as the default component type
- Reducing client-side JavaScript bundle size by keeping non-interactive components server-only
- Direct database or file-system access from within a component, without a separate API layer
- Streaming HTML to the client progressively as different parts of the tree finish rendering on the server
Projects
- Build a page with both a Server Component (fetching and rendering data directly from a data source) and a Client Component (an interactive counter), and inspect the shipped JavaScript bundle to confirm the Server Component's code never reaches the browser
- Explain, for a real page, which parts should be Server Components and which must be Client Components, and why
Examples
- A Server Component reading directly from a database and rendering a product list ships zero JavaScript for that logic to the browser — only the resulting HTML
- An 'Add to Cart' button within that same page must be a Client Component, since it needs interactivity (onClick) that only runs in the browser
Resources
Mastery checklist
- I can explain the difference between a Server Component and a Client Component
- I can decide which parts of a component tree should be server-only versus client-interactive
- I can explain why Server Components reduce shipped JavaScript compared to an all-client-side app
- I can explain how Server Components use Suspense to stream data-dependent content