Rendering on the server: the big idea

Where the HTML comes from

Compare what the browser receives for the same "About us" page.

Plain React SPA. The server sends a shell, and content appears only after the bundle runs:

<div id="root"></div>
<script src="/bundle.js"></script>

Next.js. The server runs your component first and sends the result:

<h1>About us</h1>
<script src="/chunk.js"></script>

Same component, radically different first impression. The Next.js user sees content immediately, and the crawler sees real HTML. This is server-side rendering (SSR) in its simplest form: run React on the server, ship HTML.

Hydration: waking the page up

Server-rendered HTML arrives with no event listeners attached. Click handlers, useState, and effects all require JavaScript running in the browser, and none has run yet. The page looks right but nothing responds. It is a photograph of your app rather than the app itself.

So after the HTML arrives, Next.js downloads the JavaScript for the interactive parts and hydrates them: React attaches event listeners and takes over the already-rendered DOM instead of rebuilding it. Think of the HTML arriving frozen, then thawing into a live React app.

Two consequences you will meet again in Unit 3:

• Content can be visible before it is interactive.
• Only components that actually need interactivity have to ship JavaScript to the browser at all.

The gap between readable and clickable

There is a real window in which a server-rendered Next.js page has its HTML but not yet its JavaScript. During that window the user can read everything: headings, paragraphs, prices, images. SSR ships finished HTML, so content is readable the moment it lands.

What the user cannot do yet is interact. A button wired with an onClick handler will not respond, because React event handlers only attach during hydration, after the JavaScript loads and runs. Until then the page really is a still photograph.

This is usually a good trade. Reading comes first for most visitors, and a page that is readable in 300ms and interactive at 900ms beats a blank screen until 900ms.

Recall: you rendered on a server before

This should feel familiar from Backend with Node.js: your Express handlers built responses on the server and sent them to the browser. Next.js does the same thing, except the "template" is a React component tree, and the framework handles the second act (hydration) automatically.

The mental model to carry forward:

1. Request comes in. Next.js runs your React components on the server.
2. HTML goes out. The user sees content fast, and crawlers are happy.
3. JavaScript follows. Interactive parts hydrate and come alive.

In Unit 3 you will learn that step 3 is optional per component. That is the core idea behind server and client components.

Reading the raw HTML of a Next.js store

Take a product page from a store built with Next.js and view its source, then look for the product's name, "Aurora Lamp". It is there. Next.js rendered the page on the server, so the HTML response already contains the rendered content, product name included.

Do the same on a plain React SPA and the name is absent. View Source would show only an empty root div and a script tag.

Why it works out that way

• View Source shows what the server sent, before any JavaScript runs.
• SSR does the component rendering before the response is sent, so the text is baked into the HTML.
• An SPA does it after the response arrives, so the text exists only in memory in the browser.