The 3-Renderer Rule: When to Render in the Browser, Server, or DOM

Programmatic video rendering is often treated as a monolith: you send data to a server, wait for a worker to finish, and download the file. But for modern SaaS teams, this architecture is often too slow, too expensive, or too disconnected from the user experience.

In VideoFlow, we solve this by separating the intent (the VideoJSON) from the environment. This has led to what we call the 3-Renderer Rule: a framework for deciding whether to render in the user's browser, on a headless server, or directly into the DOM for live preview.

Choosing the right environment is the difference between a snappy, interactive product and a clunky background-job pipeline. Let’s break down when to use which renderer and why the portable architecture of the @videoflow/core builder makes this possible.

1. The Browser Renderer: Zero-Cost Client-Side Export

If your users are creating short-form content, social media posts, or personalized videos, the Browser Renderer is your most powerful tool. Built on WebCodecs and Web Workers, @videoflow/renderer-browser allows you to render full MP4 files entirely inside the user's tab.

When to use it:

• User-generated content (UGC): When the user hits "Download," the render happens on their machine.
• Privacy-first apps: The raw footage never has to leave the user's device.
• Infrastructure cost reduction: You pay $0 in server compute for the actual render.

import VideoFlow from '@videoflow/core';
import VideoRenderer from '@videoflow/renderer-browser';

const $ = new VideoFlow({ width: 1920, height: 1080 });
$.addText({ text: 'Client-side Export', fontSize: 6 });
$.wait('3s');

// Render to a Blob directly in the browser
const blob = await VideoRenderer.render(await $.compile());

As we explored in our guide on zero-server video export, this approach utilizes the device's hardware acceleration to produce high-quality H.264 video without any backend overhead.

2. The Server Renderer: Scalable Headless Automation

For background tasks, batch jobs, or high-volume content factories, you need the Server Renderer. @videoflow/renderer-server runs in Node.js and drives a headless Chromium instance via Playwright.

When to use it:

• Scheduled automation: Generating weekly recap videos or daily news summaries.
• API-driven video generation: Powering a "Video-as-a-Service" endpoint.
• Complex long-form renders: When a video takes 10+ minutes to render and you don't want to keep the user's tab open.

By default, the server renderer uses a high-performance WebCodecs pipeline inside Chromium, meaning it doesn't even require FFmpeg to be installed on your host. However, if you need custom encoder flags, you can opt into a per-frame FFmpeg pipeline.

import VideoFlow from '@videoflow/core';
import '@videoflow/renderer-server'; // Registers the Node renderer

const $ = new VideoFlow({ width: 1080, height: 1920 });
$.addText({ text: 'Server-side Automation', fontSize: 8 });
$.wait('5s');

await $.renderVideo({
  outputType: 'file',
  output: './automated-video.mp4',
});

3. The DOM Renderer: The "Truth" of the Timeline

Before you export, you need to see what you're building. The DOM Renderer (@videoflow/renderer-dom) is designed for frame-accurate, 60fps live preview. It doesn't produce an MP4; it produces a visual representation of your timeline that users can scrub, play, and edit in real-time.

When to use it:

• Video editors: Powering the preview window in your React Video Editor implementation.
• Interactive dashboards: Showing a live preview of a video being generated from data.
• Debugging: Verifying that transitions and GLSL effects look exactly right.

Because all three renderers share the same underlying logic, the preview you see in the DOM is byte-for-byte identical to the pixels that will eventually be encoded by the server or browser renderers.

Why VideoJSON is the Key

The reason you can switch between these environments seamlessly is VideoJSON. Unlike other frameworks that tie your video logic to a specific React runtime or a proprietary binary format, VideoFlow treats the video as portable data.

You can author your video using our fluent builder, compile it to a JSON object, and send that object across the wire. The server can render it, the browser can export it, and the DOM can preview it—all from the exact same source of truth.

Choosing Your Strategy

Most sophisticated video platforms use a hybrid approach:

1. Use @videoflow/renderer-dom for the editing interface so users get instant feedback.
2. Attempt @videoflow/renderer-browser for the final export to save on server costs.
3. Fall back to @videoflow/renderer-server if the user's device is underpowered or if they close the tab.

Ready to see the 3-renderer rule in action? Head over to the VideoFlow Playground to experiment with live preview and browser-side export, or check out our getting started guide to set up your first server-side pipeline. If you want to see the source behind the renderers, join us on GitHub.