React Server Components: Paradigm Shift in SSR

The Hydration Problem

Historically, Single Page Applications (SPAs) shipped massive JavaScript bundles to the browser, leading to poor Time To Interactive (TTI) scores on low-end devices. Server-Side Rendering (SSR) via frameworks like Next.js improved initial page load, but the browser still had to download and execute heavy component logic to 'hydrate' the static HTML into a fully interactive state.

Zero-Bundle-Size Logic

React Server Components (RSC) fundamentally redefine this architecture. By explicitly declaring certain components to run *only* on the server environment, engineers can keep heavy formatting libraries (like Markdown parsers or Date formatters) completely out of the client-side JavaScript bundle. The server computes the final virtual DOM state and streams it directly to the browser as a specialized UI serialization format.

Interleaved Architectures

The true power of RSC lies in its ability to securely interleave execution. A Server Component can fetch data safely and directly from a private database without exposing an API endpoint or worrying about CORS. It can then pass that resolved logic down as specialized props to an inner 'Client Component' that handles strictly interactive events (like `onClick` or `onChange`), achieving the absolute best of both architectural philosophies.