The Shift in Mental Model
Before Server Components, every Next.js app I built followed the same pattern: fetch data in `getServerSideProps` or `getStaticProps`, pass it down, and let the client hydrate. It worked. But it meant the client was doing more work than necessary.
With React Server Components (RSC), the paradigm flipped. Components render on the server by default. No JavaScript goes to the client unless you explicitly opt in with the `"use client"` directive.
What Actually Changed
Bundle Size Dropped Dramatically
Large data-fetching utilities, date formatting libraries, and even heavy UI components that didn't need interactivity stayed on the server. The result? Smaller bundles, faster initial paint, and better Core Web Vitals.
Direct Database Access
Server Components can import database drivers directly. No more API routes as intermediaries for simple data queries. This simplified my architecture considerably.
Streaming Became Natural
With Suspense boundaries, I could stream parts of the page as they loaded. The skeleton appeared, content filled in progressively, and the user saw something interactive much faster.
When I Still Use Client Components
Not everything moved to the server. Interactive elements—forms, modals, real-time dashboards—still live on the client. The key insight is knowing which components need interactivity and which just need to render data.
The Verdict
Server Components didn't just optimize my apps—they changed how I think about the boundary between server and client. The result is faster, simpler, and more maintainable code.