React Server Components Explained — When to Use Them

The mental model

React Server Components (RSC) run once on the server and stream HTML to the browser. They never ship their JavaScript to the client. Client components hydrate and go interactive. The rule of thumb: default to Server Components, reach for "use client" only at interaction boundaries — forms, event handlers, browser APIs.

Data fetching without waterfalls

Server Components fetch directly with async/await, colocated with the UI that needs the data. Parallel fetches in the same component resolve concurrently. The classic mistake is nesting async server components that each await in sequence — that recreates the waterfall on the server. Hoist independent fetches to the same level or wrap sections in Suspense boundaries so slow segments stream in without blocking the page shell.

The mistakes we fix most

First, putting "use client" at the page root — one directive at the top poisons the entire tree into client JS. Push it down to leaves. Second, importing server-only modules (database clients, secrets) into client components — the build fails loudly, which is a gift. Third, forgetting that props crossing the boundary must be serializable: no functions, no class instances.

When client-first still wins

Highly interactive canvases, drag-and-drop editors, and real-time games stay client-rendered. RSC optimizes content-heavy apps — marketing sites, dashboards, feeds. Most products are 80% content: serve that from the server, hydrate the 20% that moves.

Discuss a project: /contact. Related reading: our Next.js development guide (/pillar/next-js-development-company-rajkot).