Next.js Server and Client Components: Decide Where Code Should Run

Next.js Server and Client Components

The biggest mental shift in Next.js is that not every component needs to run in the browser.

Beginners often add "use client" too quickly because browser interactivity feels familiar, but that can throw away many of the framework benefits.

Professionals use server components by default and introduce client components only where state, effects, or browser APIs are truly needed.

This lesson matters because the server-versus-client boundary affects bundle size, security, and data flow all at once.

What Beginners Usually Misunderstand

Many learners think server components are only for data fetching, but the idea is broader. If a piece of UI can be prepared without browser-only APIs or live client state, it can often remain on the server. That means less JavaScript is sent to the user.

A common beginner mistake is adding "use client" at the top of a parent component and accidentally turning a large part of the tree into client-side code when only one small button needed it.

Server components can read data and render markup without sending all that logic to the browser.
Client components are for interaction, local state, effects, and browser APIs.
The boundary should be as small as possible.

How Teams Draw The Boundary

Professionals often keep page shells, lists, and read-only data rendering on the server, then embed smaller client islands for search bars, filters, modals, or live controls. This creates a better balance between speed and interaction.

The question is not "can this be a client component?" The better question is "what is the minimum interactive surface that needs client behavior?" That framing usually produces cleaner code and smaller bundles.

Push interactivity down into narrow client leaf components.
Keep sensitive data access on the server whenever possible.
Review client boundaries during code review because they affect performance and security.

Tradeoffs To Notice

Server components cannot use browser APIs, event handlers, or React hooks like useState and useEffect. Client components can, but they add bundle weight and hydration cost. Understanding this tradeoff is more important than memorizing the syntax.

The best developers treat the boundary as an architectural decision. It changes how fast the page loads, how easy the code is to test, and what logic stays private on the server.

A server component is often better for static or read-heavy views.
A client component is necessary for immediate browser interaction.
Too many client components usually means you are rebuilding a SPA inside a framework that can do more for you.

Server shell with client island

This split is one of the most practical patterns to understand early.

Server shell with client island

export default async function ProductsPage() {
  const products = await getProducts();

  return (
    <section>
      <h1>Products</h1>
      <ProductFilters />
      <ProductList products={products} />
    </section>
  );
}

// ProductFilters.tsx
'use client';

export function ProductFilters() {
  return <button>Open filters</button>;
}

The page and list stay on the server.
Only the interactive filter control becomes client code.
This keeps the boundary small and easier to reason about.

Key Takeaways

I can explain why server components are the default in modern Next.js.
I know when a component needs "use client".
I understand that a client boundary affects bundle size and hydration.
I can describe a server-shell-plus-client-island pattern.

Common Mistakes to Avoid

Adding "use client" to large parent components without checking if a smaller child can handle the interaction.

Fetching sensitive data in the browser when it could stay on the server.

Confusing server components with old-style server rendering and missing the compositional model.

Practice Tasks

Take one imaginary dashboard page and label which parts can stay on the server and which must become client islands.
Rewrite a page concept so only the search box and modal become client components.
Explain to another learner why "use client" should be a deliberate decision instead of a reflex.

Frequently Asked Questions

Can a server component render a client component?

Yes. That is a normal pattern. The server component can provide data and structure while the child client component handles interaction.

Should I avoid client components completely?

No. Use them when the browser really needs to manage state, effects, or user interaction. The goal is not zero client code; the goal is intentional client code.

Previous Next

Next.js Server and Client Components: Decide Where Code Should Run