Server Components, explained without the jargon
React Server Components render on the server and send the client a description of the result, not JavaScript. That means no bundle cost for server rendered parts and direct database access, with client components handling only the interactive pieces.
Why it exists
Traditional React sends every component's code to the browser, even ones that only fetch data and render static markup. That inflates the JavaScript bundle and often forces an extra round trip: render a loading state, fetch data client side, render again. Server Components exist to let a component run entirely on the server, close to the database, and ship the browser nothing but the result.
The mental model
Split the component tree into two territories. Server components are like a chef preparing a finished plate in the kitchen, the browser only receives the plate, not the recipe or the ingredients. Client components are the parts of the page that still need to react to a click or a keystroke in the browser, so their actual code has to travel there. Most of a typical page, page shells, data heavy sections, static layout, can live entirely in the kitchen.
How it works
A server component executes on the server for every request, can call a database or a filesystem directly with no separate API layer, and its output is serialized into a compact description rather than HTML or JavaScript. That description streams to the client, where React reconstructs the UI without ever needing the server component's source code. Any component that needs state, effects, or browser APIs is marked as a client component, gets bundled and hydrated normally, and can only receive data from its server parent through props that survive serialization: plain objects, strings, numbers, not functions or class instances.
When it matters
It matters most on data heavy pages, dashboards, product listings, anything that would otherwise ship a large data fetching library and loading state logic to the browser for no interactive benefit. The footgun is reaching for hooks, useState, useEffect, inside a server component, they simply do not run there, and the fix is always to push that logic down into a smaller client component rather than converting the whole tree.
A concrete example
A product page component queries the database directly for price and stock, then renders that markup plus a small AddToCartButton client component, passing it only the product id and price as serializable props. The page's data fetching and query logic never reach the browser, only the button's interactive code does.
Interview question
The explainer opens by stressing that RSC is not SSR. Based on the card, why do client components need their props to be serializable?
- a.Because data has to cross the network boundary from server to client componentsCorrect
- b.Because all components in RSC apps are rendered exclusively in the browser
- c.Because SSR requires hydration but RSC does not render on the server at all
- d.Because TypeScript enforces serialization for all React props by default
Why? this is the answer
The card ties prop serialization to where the network boundary sits between server rendered and client components. The tempting wrong answer assumes RSC renders everything in the browser, which contradicts the entire premise that components render on the server.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles