Web Applications

Server Components vs Client Components: Choosing Without Guessing

Next.js made Server Components the default, and a lot of developers now sprinkle "use client" wherever something breaks until the error goes away. That works, but it ships far more JavaScript to the browser than necessary. The choice isn’t mysterious — there’s a simple rule.

Server Component by default

It renders on the server, sends HTML, and ships zero JavaScript for that component to the browser. It can fetch data directly, access the database, and keep secrets on the server. For anything that just displays data — most of a typical page — this is what you want.

Client Component only for browser behavior

Reach for a Client Component when you need state and interactivity (useState, useEffect), event handlers like onClick, or browser APIs like localStorage. If a component needs to respond to user interaction in the moment, it has to run in the browser.

The mistake is making large sections client components because one small piece inside them is interactive. Don’t. Keep the big, static parts on the server and push the interactive bit into its own small client component. A button that needs onClick should be a tiny client island inside an otherwise server-rendered page — not a reason to mark the whole page client.

Ask one question per component: does this need to run in the browser? If no, it’s a Server Component. If yes, isolate exactly the part that does.

keep reading

Related articles

Tell me what you want to build 🤝

A website, an app, some automation — or something you’re still figuring out. Tell me the problem and I’ll give you a straight answer on what it takes. No pressure, no sales team.

You’ll deal with me directly — usually a reply within a day.