The Case for Server Components

A Paradigm Shift

React Server Components (RSC) aren't just a new feature — they represent a fundamental rethinking of the React component model. For the first time, we can write components that never ship JavaScript to the client.

The Problem They Solve

Traditional React applications send the entire component tree to the client as JavaScript. Even if a component just renders static content, its code still ends up in the browser bundle. This leads to:

• Larger bundle sizes
• Longer parse and execution times
• Unnecessary hydration costs

How Server Components Help

Server Components execute exclusively on the server. They can:

• Access databases directly without API endpoints
• Read the filesystem for content
• Use server-only dependencies without bloating the client bundle
• Stream HTML progressively to the client

// This component never ships JS to the browser
async function RecentPosts() {
  const posts = await db.posts.findMany({
    orderBy: { createdAt: "desc" },
    take: 5,
  });

  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

The Mental Model

Think of it this way:

• Server Components: for data fetching, static content, and layout
• Client Components: for interactivity, event handlers, and browser APIs

The boundary between them is the "use client" directive. Everything above it is server-only by default.

Adopting Incrementally

You don't need to rewrite your entire app. Start by:

1. Moving data fetching to Server Components
2. Keeping interactive elements as Client Components
3. Using the composition pattern to combine both

The result? Faster page loads, better SEO, and simpler data fetching — without sacrificing the interactivity React is known for.