blog / server-components-vs-client-components / overview.md

Server Components vs Client Components in 60 Seconds

Still confused by the Next.js App Router? Here is the mental model you need.

Don't overcomplicate it.

Server Components (The Default)

Run only on the server.
Have direct access to the database (e.g. await db.query()).
Cannot use useState, useEffect, or onClick.
Output raw HTML. Zero JavaScript is sent to the browser for them.

Client Components ("use client")

Render on the server and hydrate on the client.
Can use state, effects, and event listeners.
Their code is bundled and sent to the browser.

The Golden Rule: Keep your Server Components at the top of your tree to fetch data, and pass that data down to small, leaf-node Client Components for interactivity.

Related Blogs

nextjs

Migrating from TanStack Start to Next.js App Router: An Architecture Post-Mortem

A deep dive into why we moved our entire CMS away from Vite SSR and TanStack Router, the performance implications of Server Components, and the hydration traps we had to fix.

react

Fixing Hydration Errors in Next.js: A Structural Approach

Hydration errors are the bane of Next.js developers. Stop fighting the warnings and learn the structural causes behind 'Text content did not match server-rendered HTML'.

build-in-public

Why I Built My Own CMS Instead of Using Contentful or Sanity

Headless CMS platforms are powerful, but they abstract away the database, limit your architecture, and introduce vendor lock-in. Here is a build-in-public look at why writing a bespoke CMS on Supabase was the best engineering decision I made.