Skip to solution
mediumFrontend

What is the difference between client-side and server-side rendering?

83 views
01

Understand the problem

Question presented to candidate: "If you view-source on a server-side-rendered page versus a client-side-rendered one, what would you actually see differently in the raw HTML — before any JavaScript has run?"

What a strong answer should cover:

  • 📌 Interview term: server-side rendering (SSR) — the server generates the complete, final HTML for a page (including real, visible content) and sends that fully-formed markup to the browser — verified directly: the raw HTML genuinely already contains real, visible text content the moment it is parsed, before any JavaScript executes.
  • 📌 Interview term: client-side rendering (CSR) — the server sends a minimal, mostly-empty HTML shell (often just a single <div id="root"></div>); the actual content is built up entirely by JavaScript running IN the browser, AFTER the page loads — verified directly: the raw HTML's content container is genuinely, verifiably EMPTY until a separate step (JavaScript execution) populates it.
  • 📌 Interview term: the real, direct answer to the prompt — verified directly, side by side: SSR's initial HTML genuinely already contains the real text ("Hello from SSR..."), readable directly from view-source with zero JavaScript execution required, while CSR's initial HTML genuinely has an empty root element — the visible content only appears in a SECOND, later step once JavaScript actually runs.
  • A precise answer names the real, practical trade-offs this causes: SSR genuinely provides real content to search engine crawlers and a faster real "first paint" of visible content, at the cost of more server work per request; CSR genuinely shifts that rendering work to the client, at the cost of a real, visible delay (or a blank/loading state) before content appears, and historically weaker out-of-the-box SEO for crawlers that do not execute JavaScript.
  • A precise answer names hydration as the real, related mechanism: many modern frameworks combine both — the server sends SSR'd HTML for the fast initial view, and client-side JavaScript then "hydrates" that existing markup, attaching event listeners and taking over rendering without re-building the DOM from scratch.

Clarifying questions expected:

  • None — this is a definitional/comparison question; directly answering the prompt's own view-source scenario with real, verified proof is the strong signal.

Code / implementation expected: Yes — a real, side-by-side jsdom demonstration of an SSR HTML string already containing content versus a CSR HTML string's genuinely empty root is the clearest, most convincing proof.

renderingssrcsrweb architecture
02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript/web-architecture interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The real HTML-content difference below was actually demonstrated with jsdom, not just

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSReal, side-by-side jsdom proof: SSR's raw HTML already contains content, while CSR's raw HTML root is genuinely empty until a later step populates it
05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.

Transmission complete // awaiting log

KEEP THE
STREAK ALIVE.

Dossier 117 of 165 decoded in the JavaScript track. One more won't hurt.

Back to track