React Server Components (RSC) landed with a lot of excitement and a fair amount of confusion. The mental model is genuinely new and it takes some time to internalize which component should live where and why.
The Core Idea
Server Components run only on the server. They can read from databases and access secrets directly without a round-trip API call. They send plain HTML to the browser and never ship their own JavaScript bundle. Client Components are the ones you know well: they run in the browser and handle interactivity.
A Simple Rule to Get Started
Start everything as a Server Component. Only reach for 'use client' when you need browser APIs, event handlers like onClick or React hooks like useState and useEffect. Most of your component tree will end up being server-rendered with only a handful of interactive leaves marked as client.
Data Fetching Is Much Simpler
In a Server Component you can just await your database query or API call directly at the top of the component function. No useEffect. No loading state wiring. No data fetching library required for straightforward reads. The data arrives already populated when the HTML is sent.
What to Watch Out For
Server Components cannot accept functions as props from client components. Keep state and event handlers in client components and pass only serializable values (strings, numbers, plain objects) down from server to client.
Conclusion
The learning curve is real but the payoff is worth it. Pages that fetch their own data on the server are simpler to reason about, faster to load and easier to test. Start with one page or one data-heavy component and expand from there.