Server-side Rendering with Hydration

Historically, SSR alone had a rough edge: once the client-side JavaScript bundle finished downloading, Angular would essentially throw away the server-rendered DOM and re-render the entire application from scratch client-side, which not only wasted the work the server had just done but also caused a visible flicker/layout shift as the real DOM was replaced. Hydration (stable since Angular 17) fixes this specifically: instead of discarding and re-rendering, Angular's client-side bootstrap process reuses the existing server-rendered DOM nodes directly, attaching event listeners and reconciling application state onto them in place, without tearing anything down.

This matters enormously for real-world metrics like Cumulative Layout Shift and produces a meaningfully smoother handoff between server-rendered and client-interactive states, but it does impose new constraints worth mentioning: code that directly manipulates the DOM outside Angular's own APIs (rather than through Renderer2 or other DOM-abstraction-respecting mechanisms) can produce a DOM structure the client-side hydration process doesn't expect, causing hydration mismatches that Angular detects and, depending on configuration, either repairs by falling back to full re-render for that section or logs as a development-time warning to fix.

A thorough interview answer also mentions that SSR (with or without hydration) requires writing isomorphic-safe code — checking for browser-only globals (window, document, localStorage) via Angular's isPlatformBrowser()/isPlatformServer() utilities before using them directly, since that code also runs in a Node.js server environment where those globals simply don't exist, and calling them unconditionally would crash the server-side render entirely.