React Server Components, explained simply

If you've seen "Server Components" in a React or Next.js post and skipped past it, this one is for you. The concept is genuinely simple — it just has an intimidating name.

The idea in one sentence

Components that don't need interactivity run on the server; components that do need interactivity run in the browser.

That's it. A Server Component is just a component that renders on the server and sends finished HTML to the client. No JavaScript bundle, no API call to fetch its own data — the data is already in the HTML.

Why that matters

Every app fetches data. Traditionally you shipped the fetching logic to the browser, which then called your API, which then queried the database. That's a round trip you can skip:

// Server Component — runs on the server, near your database
export default async function Posts() {
  const posts = await db.posts.findMany(); // no API needed
  return posts.map((post) => <PostCard key={post.id} post={post} />);
}

The browser receives the rendered cards. It never runs the database query, never ships the query code.

When do you need a Client Component?

Only when the component needs browser features: state, effects, event handlers. You opt in explicitly:

"use client";

export function LikeButton() {
  const [liked, setLiked] = useState(false);
  return <button onClick={() => setLiked(!liked)}>{liked ? "❤️" : "🤍"}</button>;
}

The rule of thumb: start as a Server Component, add "use client" only when a component genuinely needs the browser.

A real example: this blog

This site's blog is a good case study because it mixes both kinds of work:

• The post list is a Server Component — it reads Markdown files, parses frontmatter, sorts by date, and sends finished cards
• The category filter is a small Client Component — it needs state to know which filter you clicked
• The article pages are Server Components — Markdown renders to HTML before it ever reaches you

The browser only downloads the JavaScript for the filter, which is a few kilobytes. The rest of the page is HTML.

Common misconceptions

• "Server Components can't use state" — right, and they don't need to. If a component needs state, it's a Client Component by definition.
• "Everything must be one or the other" — components compose freely; a Client Component can render Server Components as children.
• "I have to rewrite my app" — no. Most existing components are already server-safe; you adopt the model gradually.

When NOT to use them

A few cases where a Client Component is the honest choice:

• Real-time updates or chat UIs
• Heavy client-side interactivity (drags, drawing canvases)
• Anything that reads window, localStorage, or browser APIs at render time

Server Components aren't a replacement for the client — they're a way to stop sending the client work it never needed.

The rule of thumb

Default to Server Components. Add "use client" only when a component genuinely needs the browser. Most pages are 90% server components, which means faster loads and smaller bundles — for free.