How is RSC (React Server Components) different from SSR (Server Side Rendering)?

Question

Accepted Answer

The key difference lies in their objectives and technical implementation: SSR is a page-level **rendering strategy** that converts the entire React component tree into HTML on the server to improve initial load time, but it still sends component JavaScript bundles to the client for hydration to make the page interactive . RSC, introduced in React 19, takes a component-level approach where specific components run exclusively on the server, never ship their code to the client, and communicate via a special serialized format rather than HTML . **Execution Location:** SSR runs on the server during the initial request to generate HTML, but the same component code also runs on the client during hydration. RSC runs exclusively on the server - its code never reaches the browser . **Output Format:** SSR produces raw HTML strings that the browser parses and displays. RSC produces a specialized serialized format (JSON-like tree description) that preserves component boundaries and allows seamless merging with Client Components . **Bundle Impact:** SSR includes component JavaScript code in client bundles for hydration, impacting bundle size. RSC sends zero JavaScript for Server Components - only Client Components (marked with `'use client'`) ship their code, dramatically reducing bundle size . // ========================= SSR ========================= // In Next.js Pages Router // Component runs on both server (for HTML) and client (for hydration) export async function getServerSideProps() { const data = await fetchData(); // Server-side data fetching only return { props: { data } }; } export default function ProductPage({ data }) { // This component hydrates on client const [count, setCount] = useState(0); // useState works after hydration return

setCount(count + 1)}>{data.name}

; } // ========================= RSC ========================= // In Next.js App Router // Server Component - runs only on server, never hydrates export default async function ProductPage() { // No 'use client' directive // Direct database access - no API endpoint needed const data = await db.product.findUnique({ id: productId }); return (

{data.name}

{/* Client Component - ships JavaScript to browser */}

); } // Client Component - runs on both server (for SSR output) and client (for interactivity) 'use client'; export function ClientLikeButton({ productId }) { const [liked, setLiked] = useState(false); return ; } RSC components can directly access databases, file systems, or any server-only APIs without creating intermediary API endpoints . In SSR, data fetching is typically separated from component rendering (e.g., `getServerSideProps` in Next.js Pages Router), creating an additional layer of abstraction. This direct server access in RSC eliminates "request waterfalls" where components wait for client-side data fetching after initial load . SSR Hydration: After the HTML loads, React hydrates the entire component tree, making all components interactive. This requires loading and executing component JavaScript, which can delay Time to Interactive . RSC Selective Hydration: Only Client Components marked with `'use client'` hydrate. Server Components never hydrate and cannot use `useState`, `useEffect`, or event handlers . This reduces JavaScript execution on the client significantly. Both technologies support streaming, but differently. SSR with modern React supports `renderToPipeableStream`, which streams HTML to the client progressively. RSC naturally supports streaming by sending component output as it resolves, and when combined with SSR (as in Next.js App Router), it creates the optimal architecture: RSC for data fetching and component composition, SSR for generating the initial HTML payload . RSC is not a replacement for SSR but a complementary technology. In Next.js App Router, Server Components (RSC) handle data fetching and static content, while SSR is used to generate the initial HTML sent to the browser. This creates a hybrid architecture where you get the bundle size benefits of RSC with the first-paint speed of SSR . The main cost is increased complexity in understanding the server-client boundary and managing which components run where .

How is RSC (React Server Components) different from SSR (Server Side Rendering)?

The foundational difference is that RSC renders components exclusively on the server to eliminate JavaScript bundle size and enable direct backend access, while SSR is a page-level strategy that generates initial HTML on the server but still sends component code to the client for hydration.

How is RSC (React Server Components) different from SSR (Server Side Rendering)?

The foundational difference is that RSC renders components exclusively on the server to eliminate JavaScript bundle size and enable direct backend access, while SSR is a page-level strategy that generates initial HTML on the server but still sends component code to the client for hydration.

Scenario Questions

Follow-up Questions