The 3-Renderer Rule: Build Video Apps That Preview, Export, and Automate

Building a video-enabled SaaS usually starts with a painful architectural split. You build a live preview in React for the user to see what they are doing, then you build a completely separate FFmpeg-based pipeline on the server to actually generate the MP4. The result? A maintenance nightmare where the preview and the final export never quite match.

At VideoFlow, we solve this with the 3-Renderer Rule. By decoupling the video definition from the rendering engine, we allow you to use the exact same VideoJSON across three distinct environments: the DOM for live editing, the browser for client-side export, and Node.js for server-side automation.

1. The DOM Renderer: Frame-Accurate Live Preview

Most video tools rely on a standard <video> tag for previewing, which is notoriously difficult to sync with custom overlays or precise keyframes. The @videoflow/renderer-dom package takes a different approach. It renders your VideoFlow timeline directly to a DOM target at a locked 60 fps.

This is the engine behind our interactive playground. Because it consumes the same JSON that the server uses, what the user sees while scrubbing the timeline is exactly what they will get in the final file. No "export and pray" cycles.

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

Server-side rendering is expensive. If you have 10,000 users exporting a 1080p video at the same time, your AWS bill will reflect it. The @videoflow/renderer-browser package leverages WebCodecs to encode MP4s directly in the user's browser tab.

This allows you to offer high-quality video exports with zero infrastructure cost. The browser renderer runs in a Web Worker, ensuring the UI remains responsive while the video is being muxed. It's the ultimate tool for client-side video export.

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

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

// Render directly in the browser tab
const blob = await $.renderVideo({ outputType: 'blob' });
const url = URL.createObjectURL(blob);

3. The Server Renderer: High-Throughput Automation

For batch jobs, scheduled social posts, or LLM-driven video agents, you need a headless environment. The @videoflow/renderer-server package runs in Node.js, driving a headless Chromium instance via Playwright.

Unlike traditional FFmpeg wrappers, our server renderer doesn't require FFmpeg to be installed on the host by default. It uses the same WebCodecs pipeline as the browser, ensuring that a video designed in the VideoFlow Playground renders byte-for-byte identical on a Linux server.

Why Portability Matters

When your video is defined as portable VideoJSON, it becomes a first-class citizen in your data stack. You can store video templates in Postgres, version-control them in Git, and diff them like source code.

This architecture is why VideoFlow is the preferred choice for teams moving away from fragile FFmpeg shell scripts. You get a typed, fluent builder API and the guarantee that your video will look the same whether it's being scrubbed by a user or rendered by a background worker.

How VideoFlow Handles This

The magic lies in @videoflow/core. The core library is responsible for compiling your builder calls into a resolution-agnostic JSON document. Because we use em units (where 1em = 1% of project width), the same JSON can render at 720p for a mobile preview and 4K for a cinematic export without changing a single line of logic.

Ready to build your own video pipeline? Check out the VideoFlow GitHub repository to see the source code for all three renderers, or dive into our official documentation to start your first project.