Lancecube Studio
Back to blog
Frontend

React Server Components vs Client Components — When to Use What

February 10, 20265 min read

React Server Components (RSCs) change how we think about data fetching and rendering. They reduce client bundle size and allow direct access to backend resources, but they're not a drop-in replacement for every component. Here's how we decide when to use server vs client components in real projects.

Default to server

We use server components for layout, static content, and data fetching that doesn't need interactivity. They can read from the DB or APIs without exposing secrets to the client and they don't ship JS for that tree. Pages and layouts are server components by default in the App Router; we keep them that way unless we need state, effects, or browser APIs.

Use client when you need

Interactivity: event handlers, useState, useEffect. Browser APIs (window, localStorage). Third-party libs that depend on the DOM or run in the browser. We mark only those subtrees with "use client" and pass data from server components as props so we keep the client bundle small and data fresh from the server.

Practical split

Our typical pattern: page and layout are server components that fetch data and render server-only sections; we wrap interactive bits (forms, toggles, charts) in client components. That gives us fast initial load, minimal JS, and clear boundaries. If you're on the App Router, start with server by default and add client only where necessary.