How to Separate Video Data From Rendering With VideoFlow

I keep seeing the same failure mode in programmatic video work: the scene logic, the export logic, and the editor logic all end up in one place. The first version works. Then preview, server render, and template tweaks each pull in a different direction.

The cleaner split is simpler: keep the video as portable data, and let the renderer decide how to execute it. That is the shape VideoFlow is built for. Its @videoflow/core package lets you define a video as code and compile it into VideoJSON, while the browser, server, and DOM renderers can all consume that same source of truth. The result is easier to maintain, easier to automate, and much harder to fork by accident.

TL;DR

Put scene structure, timing, layers, copy, and asset references in VideoJSON.
Keep renderer choice, export destination, queue logic, and upload logic outside the template.
Use browser rendering when a user wants fast export without a server hop.
Use server rendering when the job belongs in a queue or batch pipeline.
Add the React video editor only when someone needs to edit the timeline visually.

The Split That Keeps Projects Stable

The main VideoFlow idea is not “use more code.” It is “move the right kind of code into the right layer.”

In practice, that means the template should describe the video itself: scenes, text layers, image layers, timing, transitions, and the assets that belong in the project. The renderer should handle the environment: whether the output is a browser MP4, a server-side batch job, or a live preview embedded in an app.

That separation matters because it keeps the project portable. The same VideoJSON can be rendered in the browser, on a server, or inside a live DOM preview. VideoFlow also keeps the core and renderers open source under Apache-2.0, which makes this easier to treat as infrastructure instead of a locked-in black box.

If you want the browser/server split in more detail, How I Built a Browser-to-Server Video Workflow With VideoFlow covers that path. For the broader multi-renderer pattern, How I Built a JSON-First Video Workflow for Browser, Server, and React is the companion read.

What Belongs In Data, Not In The Renderer

A useful rule is to keep anything that describes the video in the data layer, and anything that describes how the video is produced in the rendering layer.

Put this in the template:

Scene order.
Layer timing.
Text content.
Image and video references.
Dimensions and layout rules.
Animation intent such as a title fading in or a card sliding up.

Keep this out of the template:

Which queue receives the job.
Whether export happens in the browser or on the server.
Where the final MP4 is stored.
How a user uploads a file.
Which publish destination gets the finished asset.

That line saves a lot of pain later. Once people start putting business logic and delivery logic into the template, every new channel creates another fork. That is the opposite of what a portable video system is supposed to do.

If you are seeing that drift already, How I Keep Product Video Templates Stable as Data Changes is the follow-up I would read next.

A Workflow I Would Actually Ship

Here is the shape I would use if I were starting today:

Author the scene with @videoflow/core.
Compile it into VideoJSON.
Preview it in the browser or in the DOM renderer.
Export it in the browser when you want to avoid server upload and render costs.
Send it to the server renderer when the work belongs in a batch job, queue, or API.
Add the React editor only when another person needs to adjust the timeline without touching code.

The browser renderer is a good fit when someone clicks Export inside your app and you want the file to render in place. The server renderer is the better choice for scheduled jobs, queues, or anything that needs a headless process. The DOM renderer is the preview layer when you want scrubbing and frame-accurate playback in the UI.

That is also why VideoFlow is a better fit for structured, repeatable, template-driven video work than for ad hoc manual editing. It is built for workflow shape, not just for encoding.

The same model shows up in How to Build a Three-Renderer Video Workflow With VideoFlow and How to Build a VideoJSON Pipeline for Browser, Server, and React, if you want the implementation angle.

Where The React Editor Fits

The React editor is useful when the timeline has to be edited by someone who does not want to live in the codebase. That usually means a content team, a marketing team, or a builder shipping an internal tool.

VideoFlow's @videoflow/react-video-editor gives you a drop-in React component with a multi-track timeline, drag, trim, snap, keyframes, undo/redo, uploads through callbacks, and theme support. That keeps the editing experience close to the same portable source of truth instead of inventing a separate model just for the UI.

The important thing is not to let the editor become a second source of truth. If the template changes in the editor, it should still resolve back to the same JSON structure the renderers use.

If you want the editor-specific breakdown, How I Built a React Video Editor Around Portable JSON with VideoFlow goes deeper on that side of the stack.

The Practical Payoff

Once the split is clear, the whole system gets easier to reason about.

Product and marketing teams can reuse the same template instead of rewriting it per channel.
Developers can swap render targets without rewriting scenes.
Preview, export, and editing can evolve independently.
You can keep the template in Git, diff it, and automate it without turning every change into a one-off project.

That is the real value of a VideoJSON-first workflow: less duplication, fewer forks, and a video stack that behaves more like maintainable software.

If you want to try the pattern, start with the VideoFlow docs and the playground. Build one template, compile it to VideoJSON, and render the same output in the browser and on the server before you add any extra UI.

Next Step

Pick one existing video flow in your stack and separate the scene data from the rendering path. Once that split is in place, VideoFlow can handle the portable template, the browser preview, the server export, and the editor without forcing you to maintain four different versions of the same idea.