Server Components vs Client Components in Next.js

The single biggest source of confusion for developers new to the Next.js App Router is the split between server and client components. Once the model clicks, it's simple — and it makes your apps faster.

The default is the server

Every component in the `app/` directory is a server component unless you add `"use client"` at the top of the file. Server components render on the server, can be async, and never ship their code to the browser. That means smaller bundles and direct access to your backend.

When you need a client component

• You use `useState`, `useReducer`, or `useEffect`.
• You attach event handlers like `onClick` or `onChange`.
• You use browser-only APIs (`localStorage`, `window`, `IntersectionObserver`).
• You use a library that depends on React context or hooks on the client.

How they compose

Server components can render client components, but not the other way around — a client component can't import a server component. The pattern that solves almost every case: keep pages and data-fetching on the server, and pass server-fetched data down into small client 'islands' as props or via the `children` prop.

Common mistakes

Marking a whole page `"use client"` just to use one button turns your entire tree into client code and loses the benefits. Instead, push `"use client"` down to the smallest interactive leaf. Also avoid passing non-serializable values (functions, class instances) from server to client components — only plain data crosses the boundary.

KitCraft templates model this boundary carefully — server components for data and layout, tightly-scoped client islands for interactivity — so you can learn the pattern from real, production code.