Server Components and the Renaissance of Server-Side Rendering

## The Pendulum Swings Back

Web development has a history of swinging between extremes. We moved from purely server-rendered PHP/Ruby apps to heavy client-side Single Page Applications (SPAs). Now, with technologies like React Server Components (RSCs) and Next.js App Router, the pendulum is swinging back to the server—but this time, with the interactivity of the client intact.

### What are React Server Components?

Traditionally, React components run on the client (the browser), requiring the user to download the JavaScript bundle for the component before it can render and become interactive.

**Server Components** render exclusively on the server. Their code is never sent to the client. Instead, the server sends a serialized description of the UI, which the browser uses to construct the DOM.

### Why This Matters

1. **Zero Bundle Size:** Since Server Components don't send their JS to the client, you can use heavy libraries (like a markdown parser or date formatter) without impacting the user's download size.

2. **Direct Backend Access:** You can query your database directly inside the component without creating an intermediate API route.

3. **Improved Initial Load:** The browser receives pre-rendered HTML, meaning the user sees content instantly rather than waiting for JS to execute.

### The Client Component Boundary

RSCs introduce a new mental model: the **Client Boundary**. By default, all components in Next.js 13+ are Server Components. If you need interactivity (like `useState`, `onClick`, or browser APIs), you must explicitly opt-in by adding `"use client"` at the top of the file.

This forces developers to be intentional about what JavaScript gets shipped to the user, leading to naturally faster and more performant web applications.