What Are Server and Client Components?
In the Next.js App Router, every component is a Server Component by default. Server Components render entirely on the server (or at build time), never ship their own JavaScript to the browser, and can directly access backend resources such as databases, the file system, or environment secrets without an API layer in between. A Client Component is created by adding the 'use client' directive at the very top of a file; only then does React hydrate that component in the browser so it can use state, effects, and event handlers.
Cricket analogy: It's like a match referee (server) making the lbw decision using full stump-camera data nobody in the stands can see, versus the scoreboard operator (client) who only updates the display and reacts to button presses from the crowd.
The 'use client' Boundary
Adding 'use client' to a file marks a boundary in the component tree: that component and everything it imports (unless passed in as children) become part of the client JavaScript bundle. A common mistake is putting 'use client' at the top of a large page and dragging every child import into the bundle. The composition pattern avoids this by passing Server Components down as 'children' or other props into a Client Component wrapper -- the Server Component subtree still renders on the server even though it's nested inside a client boundary.
Cricket analogy: It's like a franchise signing one overseas star player (the client boundary) but keeping the rest of the domestic squad (server components) on the local roster instead of importing the entire foreign support staff too.
Data Fetching Differences
Server Components can be declared as async functions and await a fetch call or a direct database query right at the top of the function body, with the resolved data flowing straight into JSX -- no useEffect, no loading spinner boilerplate. Client Components cannot be async in this way; they fetch data with useEffect, a library like SWR or TanStack Query, or by receiving already-fetched data as props from a parent Server Component, since the async render model only applies on the server.
Cricket analogy: A curator (server component) can walk into the pitch report room and read the soil moisture data directly before the match starts, while a commentator (client component) has to wait for someone to radio the update to the booth mid-over.
// app/products/[id]/page.tsx -- Server Component (default, no directive needed)
import { LikeButton } from './like-button';
async function getProduct(id: string) {
const res = await fetch(`https://api.example.com/products/${id}`, {
next: { revalidate: 60 },
});
return res.json();
}
export default async function ProductPage({ params }: { params: { id: string } }) {
const product = await getProduct(params.id);
return (
<article>
<h1>{product.name}</h1>
<p>{product.description}</p>
{/* Only this small island hydrates in the browser */}
<LikeButton productId={product.id} initialLikes={product.likes} />
</article>
);
}
// app/products/[id]/like-button.tsx -- Client Component
'use client';
import { useState } from 'react';
export function LikeButton({ productId, initialLikes }: { productId: string; initialLikes: number }) {
const [likes, setLikes] = useState(initialLikes);
return (
<button onClick={() => setLikes((n) => n + 1)}>
❤️ {likes}
</button>
);
}
Server Components cannot use useState, useEffect, useContext, browser-only APIs (window, localStorage), or event handlers like onClick. If a component needs any of these, it must be a Client Component, or the interactive part must be extracted into a small child Client Component.
When to Choose Which
The practical rule is to default to Server Components everywhere and only add 'use client' at the leaves of the tree that genuinely need interactivity, local state, effects, or browser APIs -- things like a form input, a dropdown menu, a chart with hover tooltips, or a modal. Keeping data-fetching, layout, and static content in Server Components reduces the JavaScript bundle sent to the browser, improves Time to Interactive, and avoids waterfalls caused by client-side fetching.
Cricket analogy: A captain doesn't rotate the whole XI every over -- only the specific bowler (client component) needed for the situational match-up comes on, while the rest of the settled batting line-up (server components) stays put.
Marking a high-level layout or page component with 'use client' just to use one small piece of state can accidentally convert the entire subtree into client-rendered code, ballooning your JavaScript bundle. Push 'use client' as far down the tree as possible.
- Server Components are the default in the App Router; they render on the server and ship no JS to the browser.
- 'use client' at the top of a file marks a boundary; the component and its direct imports join the client bundle.
- Passing Server Components as children/props into Client Components keeps them server-rendered even when nested inside a client boundary.
- Server Components can be async functions that await fetch/database calls directly; Client Components need useEffect or a data library.
- Client Components are required for useState, useEffect, useContext, event handlers, and browser-only APIs.
- Best practice: default to Server Components, and push 'use client' down to the smallest interactive leaf possible.
- Overusing 'use client' at high levels of the tree inflates the JavaScript bundle and hurts performance.
Practice what you learned
1. In the Next.js App Router, what is the default rendering mode for a component if no directive is added?
2. Which of the following can a Server Component do that a Client Component cannot?
3. What is the effect of adding 'use client' to a file at a high level in the component tree?
4. How can a Server Component still appear inside a Client Component's rendered output without becoming part of the client bundle?
5. Which of these requires a Client Component in Next.js?
Was this page helpful?
You May Also Like
Static Site Generation
Learn how Next.js pre-renders pages to static HTML at build time using Static Site Generation, and when it's the right rendering strategy.
Server-Side Rendering
Understand how Server-Side Rendering (SSR) generates HTML on every request in Next.js, and how it differs from static generation.
Streaming and Suspense
Learn how Next.js streams HTML from the server using React Suspense so pages can show content progressively instead of waiting on the slowest data fetch.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics