I've been writing React since 2019. For years, my mental model was simple: everything renders on the client, data comes from API calls in useEffect, and state management libraries glue it all together.
Server Components broke that model — and I'm glad they did.
The old world
In a typical React SPA, the flow looks like this: the browser downloads your JavaScript bundle, React boots up, components mount, useEffect fires, data fetches begin, loading spinners appear, data arrives, and finally the user sees content.
That's a lot of steps between "user clicks link" and "user sees page."
The shift
With Server Components, the flow is: the server renders your component tree, resolves all data dependencies, and sends finished HTML to the browser. No loading states. No waterfalls. No bundle cost for server-only code.
The mental model shift is subtle but profound: instead of thinking "how do I fetch data and manage its lifecycle?", you think "what data does this component need?" and just... use it.
What I kept client-side
Not everything belongs on the server. My rule of thumb:
- **Server**: data fetching, heavy computation, components that don't need interactivity
- **Client**: forms, animations, anything that responds to user events, anything using browser APIs
The key insight is that client components should be leaf nodes — small, focused interactive pieces that receive data from their server-rendered parents.
The practical wins
- **No loading states for initial data** — pages arrive complete
- **Smaller bundles** — server-only code never ships to the browser
- **Simpler data flow** — no client-side cache invalidation, no stale data bugs
- **Better SEO** — search engines get fully rendered HTML
It's not perfect
The DX can be rough. The "use client" boundary creates friction. Error messages are sometimes cryptic. And the mental overhead of thinking about where code runs is real.
But for content-heavy applications — portfolios, blogs, dashboards — the tradeoff is overwhelmingly positive.