Server components
Slap yourself if
You think server components are just SSR with better DX or a way to hide API calls.
Why this exists
Server components exist because shipping code to the browser is expensive, stateful, and long-lived. Many parts of a UI never need to execute on the client, yet traditional architectures force them to.
Mental model
A server component is not rendered on the server instead of the client — it is executed on the server and never exists in the client runtime at all. The output is data, not behavior.
- Server components execute in a server runtime with full backend access.
- They produce a serialized description of UI, not client-side code.
- The client receives a stream of render output and stitches it together.
- Client components hydrate only where interactivity is required.
- Treating server components as faster client components.
- Leaking server-only assumptions into client boundaries.
- Over-fragmenting the tree and increasing coordination cost.
- Assuming server components eliminate all client state complexity.
Server components are UI components that execute exclusively on the server, never ship their code to the client, and stream render output to be composed with client components for interactivity.
- Fetching data in client components by default
- Passing large serialized props across boundaries
- Assuming server components are free to recompute
- Blurring server/client responsibility lines
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.