Server Components, Explained for People Who Ship Products

React Server Components have gone from experimental to the default in modern frameworks like Next.js. If you build products with React, they change some basic assumptions about where code runs. The documentation is thorough; this is the practical version.

The one-sentence version

Server Components run only on the server and send finished UI to the browser — without sending their own JavaScript.

Traditional React components are shipped to the browser as JavaScript, which then runs to produce the interface. Server Components do their work on the server, so the browser receives the result, not the code that produced it.

Why that matters

Less JavaScript for users

A component that formats a blog post with a markdown library, a date library and a syntax highlighter would traditionally ship all three libraries to every visitor. As a Server Component, those libraries stay on the server. The visitor downloads only the resulting HTML.

Less JavaScript means faster loading — especially on mid-range phones and slower connections.

Data fetching where the data lives

Server Components can be async and read data directly — from a database, a file or an internal API — without building a separate API endpoint first.

// A Server Component: runs on the server, ships no JS
export default async function LatestPosts() {
  const posts = await db.post.findMany({ take: 10, orderBy: { date: "desc" } });
  return (
    <ul>
      {posts.map((p) => (
        <li key={p.id}>{p.title}</li>
      ))}
    </ul>
  );
}

No useEffect, no loading-state juggling, no client-side request waterfall.

Secrets stay secret

Because the code never reaches the browser, API keys and database credentials used in Server Components aren't exposed. (You still need to be careful about what data you pass down to client components — anything passed to them is sent to the browser.)

Where Client Components still belong

Server Components can't use state, effects or browser APIs. Anything interactive needs a Client Component, marked with "use client" at the top of the file:

• Forms with live validation
• Dropdowns, modals and tabs
• Anything using useState, useEffect or event handlers
• Code that needs window, localStorage or other browser APIs

The skill is in the split: keep most of the page as Server Components and push interactivity down into small client "islands."

A good mental model

Think of a product page:

• Server: page layout, product details, reviews list, related products — all read data and render.
• Client: the "Add to cart" button, the image carousel, the size selector.

The server components can render client components and pass them data as props. The reverse — importing a Server Component inside a Client Component — doesn't work, though you can pass Server Components to client ones as children.

Common mistakes

Marking everything "use client". It works, but you lose the benefits. Start without the directive and add it only where interactivity requires it.

Putting "use client" too high. The directive applies to that file and everything it imports. Marking a layout as a client component drags the whole tree to the browser. Move it down to the smallest interactive piece.

Passing too much data to the client. Props passed to Client Components are serialised into the page. Passing an entire user record when the component needs a name sends the whole record to the browser.

Forgetting caching. Server Components can run on every request. Learn your framework's caching and revalidation model so pages are fast without being stale.

Should you adopt them?

If you're starting a new React project in a modern framework, you're already using them — they're the default. For existing apps, migrate gradually: new pages and features first, and convert heavy, mostly static components where the JavaScript savings are largest.

The payoff is real: faster pages, simpler data fetching and less code in the browser. The cost is learning to think about where each piece of your interface should run. After a few weeks, that question becomes second nature.