SSR and Hydration

The plain-language idea

Server-side rendering means Angular runs your components on the server, produces real HTML, and sends that to the browser — so the user sees content immediately instead of a blank page waiting for JavaScript to load and run. But raw HTML isn't interactive: clicking a button in that server-rendered markup does nothing until Angular's client-side code takes over.

Hydration is that handoff. The naive approach would be for the client to just re-render everything from scratch and swap it in — but that means the DOM the user is already looking at gets destroyed and rebuilt, causing a visible flicker and losing things like scroll position or focus. Angular's modern hydration is non-destructive: the client-side app recognizes the server-rendered DOM that's already sitting in the page, attaches its event listeners and reactive machinery to those existing elements, and skips re-creating them. The app "wakes up" in place instead of being reborn.

See it in a real thing: enabling hydration

// app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideClientHydration, withEventReplay } from '@angular/platform-browser';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    provideClientHydration(withEventReplay()),
  ],
};

provideClientHydration() is the switch that turns on non-destructive hydration for the whole app — without it, an SSR'd Angular app would still fully re-render client-side and discard the server DOM, which is exactly the flicker-and-flash pattern hydration exists to avoid. withEventReplay() closes a specific gap: there's an unavoidable window between "HTML is visible" and "Angular's JavaScript has finished loading and attached its listeners," and if the user clicks a button during that window, a naive setup would just drop the click. Event replay buffers interactions that happen during that gap and replays them once the app is actually ready to handle them — so a fast click on a slow connection doesn't silently vanish.

What people usually miss

Watch out

• Assuming SSR alone makes an app "fast." SSR improves what the user sees first (a fast first paint of real content), but the app isn't actually interactive until hydration completes — a big enough client bundle can still leave a real gap between "looks ready" and "is ready."
• Forgetting hydration needs the server and client render to match. If a component's server-rendered output and its first client-rendered output disagree — different data, different conditional branches — Angular can't safely reuse the existing DOM and has to fall back to re-rendering that subtree, which reintroduces the exact flicker hydration was meant to prevent.
• Treating withEventReplay() as optional polish. On a slow connection or a large page, the gap between "visible" and "interactive" can be long enough that real users click things during it — without event replay, those clicks are just lost, not queued.

The genealogy: waking up a server-rendered app

This is the same problem this platform's Next.js track covers under hydration and streaming — a server sends real markup first, and the client has to attach behavior to it without a jarring rebuild, and both frameworks converge on the same non-destructive strategy for the same reason. It also mirrors what React's own hydration lesson on this platform describes for hydrateRoot(): reusing existing DOM nodes instead of discarding and recreating them is the shared idea, even though the two frameworks implement the reconciliation differently underneath.