Why HyperFrames Ditched React for Video Rendering
July 14, 2026 · blog
HyperFrames is an open-source video rendering framework that takes a fundamentally different approach from React-based tools like Remotion. I've been exploring its architecture and the design decisions behind it are worth discussing.
The Remotion Problem
Remotion is clever: write your video as React components, use useCurrentFrame() for timing, and it renders each frame by mounting your component tree in Chrome and screenshotting.
In practice, the trade-offs are significant:
- Slow. A 4-minute video at 30fps = 7,200 frames. Each frame: mount React tree, trigger effects, wait for layout, screenshot. This can mean 6–10 minutes of render time for 4 minutes of content.
- Non-deterministic. React's reconciler has timing edge cases. Effects fire in unpredictable order under load. Same code, slightly different output between runs.
- Heavy dependency. React, Webpack, the entire Remotion runtime. For what amounts to "position text and images on a timeline."
Remotion's interactivity model isn't what video rendering actually needs.
What Video Rendering Actually Needs
- Deterministic output. Same input → identical pixels every time. No wall-clock dependencies, no async races.
- Seekable. Jump to frame 3,847 and get the correct visual state instantly. No playing forward from frame 0.
- Fast. Sub-30-second render for a 4-minute video.
- AI-agent friendly. Agents should be able to request a video and get predictable results.
React gives none of these guarantees by design. Its model is "render based on current state" not "render the exact state at timestamp T."
HyperFrames' HTML-First Approach
The key insight in HyperFrames: HTML + CSS is already a deterministic layout engine. Add absolute positioning for timing (data-start, data-duration attributes), and you have a video composition format that any browser renders identically.
No React. No virtual DOM. No reconciliation. Just static HTML that the renderer seeks to a specific time and screenshots.
Animations via GSAP, CSS, or Web Animations API — all paused, all registered globally, all seekable. The renderer says "go to time T" and every animation jumps to its correct state at T. No playback, no forward simulation.
The Speedup
Remotion (React, per-frame mount): 6–10 minutes for 4 minutes of video.
HyperFrames (static HTML, seek + screenshot): 20–30 seconds for the same content.
The difference: no re-mounting a component tree per frame. The HTML is loaded once. For each frame, animations are seeked and pixels are captured. The DOM doesn't change structure between frames — only positions, opacities, and transforms update.
The Trade-Off
HyperFrames loses Remotion's developer experience — no hot reload preview, no React devtools, no familiar component model. The authoring format is raw HTML with data attributes.
But if your consumers aren't developers writing React — they're AI agents generating video from structured prompts — the authoring format doesn't matter. Only the output quality and speed do.
This is an impressive architectural decision that makes the right trade-off for the AI-native video generation use case.