How does server-side rendering work in Vue (renderToString, hydration)?

Q: How does server-side rendering work in Vue (renderToString, hydration)?

**Target Audience:** Vue developers who have built client-side apps and now need to explain or adopt SSR. No prior SSR experience assumed. **Difficulty:** Hard > **How to read this doc:** Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. Every output block in the "Verified" sections was produced on Vue 3.5.44: rendered with @vue/server-renderer in Node and hydrated in jsdom with createSSRApp . Compiler output comes from @vue/compiler-sfc 3.5.44. ## 1. Why This Even Matters — A Story First Imagine ordering flat-pack furniture. With a normal Vue SPA the shop sends you a box of parts and an instruction booklet. Until you have read the booklet and screwed everything together, you have nowhere to sit. That is **client-side rendering**: the browser downloads an empty <div id="app"> , downloads JavaScript, runs it, and only then is ther

The problem

Question presented to candidate: "Our Vue storefront is a client-rendered SPA and the marketing team says search engines and slow phones see a blank page first. Walk me through how server-side rendering works in Vue: what happens on the server, what gets sent, and what the browser does with it."

What a strong answer should cover:

The server runs the same components and turns them into an HTML string with renderToString (or a stream) from vue/server-renderer; templates are compiled into string-concatenating ssrRender functions.
Only setup(), onServerPrefetch and render run on the server. onMounted and other DOM hooks do not, and there is no reactivity-driven re-render.
The browser receives real markup (fast first paint, crawlable), plus the JS bundle and serialised state.
Hydration: createSSRApp(...).mount() walks the existing DOM, attaches event listeners and adopts the nodes instead of re-creating them; createApp would throw the markup away.
The app factory pattern (fresh app and store per request) to avoid cross-request state pollution.
Costs: server CPU, a Node runtime to host, code that must not touch window during setup, and hydration mismatches.

Clarifying questions expected:

"Is the content per-user, or could some pages be prerendered at build time instead?"
"Do we want to own the server setup, or use a framework such as Nuxt?"

Code / implementation expected: Optional — a minimal server that calls renderToString plus a client entry that hydrates with createSSRApp.

vue
ssr
hydration

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Vue developers who have built client-side apps and now need to explain or adopt SSR. No prior SSR experience assumed. Difficulty: Hard

How to read this doc: Ideas are explained in plain language first, then tagged with 📌 Interview term: so you also learn the words an interviewer listens for. Every output block in the "Verified" sections was produced on Vue 3.5.44: rendered with @vue/server-renderer in Node and hydrated in jsdom with createSSRApp. Compiler output comes from @vue/compiler-sfc 3.5.44.

1. Why This Even Matters — A Story First

Imagine ordering flat-pack furniture. With a normal Vue SPA the shop sends you a box of parts and an instruction booklet. Until you have read the booklet and screwed everything together, you have nowhere to sit. That is client-side rendering: the browser downloads an empty <div id="app">, downloads JavaScr

The solution is hidden so you can try first

12 min read · 12 sections

Read the code

Minimal SSR round trip: app factory, renderToString server, hydrating client

// ── app.js ──────────────────────────────────────────────
// app.js: shared by server and client. A FACTORY, so every request gets fresh state.
import { createSSRApp, h, ref } from "vue";

export function createApp(initialState) {
  const todos = ref(initialState.todos);
  const app = createSSRApp({
    setup() {
      const add = () => todos.value.push(`Task ${todos.value.length + 1}`);
      return () => h("main", [
        h("h1", "Todos"),
        h("ul", todos.value.map((t) => h("li", { key: t }, t))),
        h("button", { onClick: add }, `Add (${todos.value.length})`),
      ]);
    },
  });
  return { app, state: { todos } };
}

// ── server.js ───────────────────────────────────────────
// server.js: render to a string, embed the state, send one HTML document.
import http from "node:http";
import { renderToString } from "vue/server-renderer";
import { createApp } from "./app.js";

http.createServer(async (req, res) => {
  if (req.url !== "/") return res.writeHead(404).end();
  const initialState = { todos: ["Write docs", "Ship 3.5"] }; // e.g. from a database
  const { app } = createApp(initialState);
  const html = await renderToString(app);
  // JSON inside <script>: escape "<" so a value like "</script>" cannot end the tag early.
  const state = JSON.stringify(initialState).replace(/</g, "\\u003c");
  res.setHeader("content-type", "text/html");
  res.end(`<!doctype html><html><body>
<div id="app">${html}</div>
<script>window.__STATE__ = ${state}</script>
<script type="module" src="/client.js"></script>
</body></html>`);
}).listen(5265);

// ── client.js (bundled for the browser by Vite or esbuild) ──
// client.js: same app, same state, then hydrate the existing DOM instead of re-creating it.
import { createApp } from "./app.js";
const { app } = createApp(window.__STATE__);
app.mount("#app"); // createSSRApp + mount over server markup = hydration

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.