HyperFrames vs Remotion

Both tools turn code into video. They take very different routes. This page is the comparison we wish existed when we were choosing — no straw-manning, no "10x better" claims.

What you'll learn

• The core architectural difference between the two
• Which projects each tool is the obvious pick for
• Where they genuinely overlap and either will do

The short version

Remotion is a React framework for video. You write JSX components, run a dev server, use the npm ecosystem.

HyperFrames is a renderer for plain HTML. You write a static document, run a CLI, ship an MP4.

If your team lives in React, Remotion will feel native. If your video is being authored by an LLM, a designer, or a CMS, HyperFrames is the shorter path.

Comparison

When Remotion wins

• Your team is already a React shop and you want types, hooks, and shared components in your video code.
• You're building a long-form, hand-tuned piece (an explainer, a YouTube channel intro library, a course) where authoring ergonomics matter more than throughput.
• You want a thick library of pre-built components and a vibrant Discord — Remotion has both.
• You need tight integration with React state for a complex interactive preview.

When HyperFrames wins

• An LLM (or non-developer) is writing the video. One HTML file fits in a prompt; a React project does not.
• You're rendering thousands of personalized clips from a CSV or database. The {{$VAR}} token model + --variants flag was built for this.
• You want the video to live in the same repo as the marketing site, lint with your existing CSS rules, and diff cleanly in PRs.
• You don't want to take on React as a dependency for a five-second logo sting.
• You want the output to be byte-identical so you can content-hash it for caching.

Where they overlap

For a single 10-second promo authored by a developer, the choice barely matters. Both will produce a clean MP4 with frame-accurate animation. Pick whichever your team will enjoy maintaining six months from now.

Both tools also share the same engine bones — headless Chrome to render frames, FFmpeg to mux. Performance characteristics are similar. The interesting differences are at the authoring layer, not the render layer.

Migration sketch

Going from Remotion to HyperFrames usually looks like this:

1. Replace useCurrentFrame() with CSS animations driven by animation-delay and animation-duration.
2. Replace <Sequence from={X} durationInFrames={Y}> with data-start and data-duration on the element.
3. Replace prop drilling with {{$VAR}} tokens and a variants JSON file.
4. Replace npx remotion render with hyperframes render.

You lose JSX. You gain a single file that anything can author.

Going the other way (HyperFrames to Remotion) usually means you've outgrown the template model and want full programmatic control — at which point Remotion's React-first design genuinely helps.

A pragmatic stance

Use Remotion when the video is the product and a React developer owns it. Use HyperFrames when the video is an artifact — generated by a workflow, a template, a CSV, or an AI agent — and you want the authoring surface to be as boring as a web page.

We built HyperFrames because we wanted to write a .html file, commit it, and have CI render the MP4. If that resonates, you're in the right place.

Next

• Programmatic video from data
• Personalized video at scale