React Server Components (RSC) flipped the mental model of how we build React apps. If you're still building everything client-side, you're leaving performance on the table.
The Core Idea
Server Components run on the server and send HTML to the browser — no JavaScript bundle, no hydration cost. Client Components run in the browser as always. The trick is knowing which to use when.
When to Use Server Components
When to Stay Client-Side
Practical Example
// This runs on the server — no bundle cost
async function BlogList() {
const posts = await db.posts.findMany(); // Direct DB access
return posts.map(p => <BlogCard key={p.id} post={p} />);
}
// This runs on the client — interactivity
'use client';
function LikeButton({ postId }) {
const [liked, setLiked] = useState(false);
return <button onClick={() => setLiked(true)}>Like</button>;
}Performance Numbers
For a recent client project (a SaaS dashboard), moving data-heavy pages to Server Components reduced the JS bundle by 42% and improved LCP by ~800ms. That's the kind of gain that matters for real users.
The Learning Curve
The hardest part is unlearning old patterns. You can't use context in Server Components. You can't useState. But once you build a few features this way, the separation of concerns becomes cleaner than anything before it.
We use this stack on every new project now. If you're starting a Next.js project, start with RSC-first architecture.
