Skip to content

CONCEPT Cited by 1 source

Universal rendering (Zalando Rendering Engine)

Definition

In the Zalando / web-frontend-platform sense, universal rendering (sometimes isomorphic rendering) is the property that one codebase runs in both a Node.js backend (to produce the initial HTML response for SSR) and in the browser (to resume rendering, hydrate, and continue re-rendering on client interactions) — with the same component source acting as both the server's template and the client's interactive runtime.

This is distinct from Google's indexing-pipeline usage of the phrase (see concepts/universal-rendering for that sense: every indexable HTML page gets full rendering, not a subset). Both uses exist in the industry; they share the word and almost nothing else.

Canonical Zalando instance

The Rendering Engine consists of "a backend service written in TypeScript and running in NodeJS coupled to a client-side Javascript module that runs in the browser" (Source: sources/2021-09-08-zalando-micro-frontends-from-fragments-to-renderers-part-2).

  One Renderer source (React + TypeScript)
               │
       ┌───────┴───────┐
       ▼               ▼
   Node.js          Browser
   (runs on         (runs on
    every             hydration +
    request)          re-renders)
       │               │
   streams           resumes
   HTML              interactivity

For the Web use case, the Rendering Engine:

  1. Receives the request on Node.js.
  2. Runs the Renderer lifecycle (withQueries + withProcessDependencies + withRender).
  3. Converts the returned React element tree to HTML via React's server renderer.
  4. Streams the HTML to the client (see concepts/streaming-ssr).
  5. Client-side, hydrates the markup with the data — the same Renderer runs in the browser, attaches event handlers, and from then on re-renders normally (see concepts/react-hydration).

The same pipeline, a different output (Native apps)

The Rendering Engine's universal shape extends past Web. The same Renderer source can be committed to Native-app output by swapping the React host-tree target: a custom React reconciler consumes the same React element tree but emits app-compatible JSON instead of HTML. From the post:

"Renderers relied on React for their output. To cover the app-specific use case, we added a custom React reconciler that consumed custom React elements, and output app-compatible JSON instead of HTML. Now, web developers are able to contribute Native apps features by reusing the same set of APIs as they were used to deliver web experiences."

So universal rendering at Zalando spans three execution environments:

  • Node.js backend (SSR path, produces HTML).
  • Browser (CSR / hydration path, produces DOM mutations).
  • Native apps (via custom reconciler, produces JSON).

Why teams choose it

  • One source of truth per component. Business logic, layout, and data-binding live in one file, not forked per environment.
  • SSR benefits without CSR loss. Initial HTML is fast to first paint (indexing-friendly, perceived-perf wins); post-hydration, the page behaves as a full SPA.
  • Contribution surface is the component, not the environment. Feature teams write Renderers; the platform team owns the Node.js and browser runtimes that execute them. Extension to Native (via reconciler) is a platform-team concern, not a per-Renderer concern.
  • Uniform test surface. A Renderer can be unit-tested once; behaviour in Node.js and browser converges.

Known constraints

  • Requires the same engine in both environments. Any divergence (different React version, different data fetching) reintroduces the drift universal rendering was meant to eliminate.
  • Hydration mismatches become load-bearing failures. See concepts/hydration-mismatch — if the server-rendered markup does not exactly match what the browser produces on first render, React warns or tears down the subtree. This becomes stricter under React 18 (sources/2023-07-10-zalando-rendering-engine-tales-road-to-concurrent-react).
  • Server-side code must be browser-safe. No direct fs, DOM, or Node-only APIs in shared Renderer code — those belong in the platform layer.

Contrast with the Googlebot sense

  • Zalando's universal rendering: one codebase, many environments, one rendering engine in each. Property of the application.
  • Google's universal rendering: every crawlable HTML page gets full WRS rendering, no heuristic skip. Property of the indexing pipeline.

The two are unrelated. A site can be built with Zalando-sense universal rendering regardless of whether it is being Googlebot-rendered, and vice versa.

Seen in

Last updated · 550 distilled / 1,221 read