Remotion and Hyperframes

Module 1 argued that video becomes a different kind of artifact when it is defined in code: diffable, regenerable, fed by the same tokens as the product. This module is the practical half of that argument — the two stacks that currently have a credible agent story, and the working habits that make either of them maintainable past the first clip.

Name the two upfront so nobody spends the module waiting for a verdict. Remotion is the established React-based framework: compositions are components, frames are computed from a frame number, and rendering scales from a laptop to distributed cloud functions. Hyperframes is the newer HTML-native option built explicitly for agents: a composition is a plain HTML file with timing attributes, animated with the web's existing libraries, rendered with headless Chrome. Both are real, both ship agent skill packs, and the choice between them is structural rather than qualitative.

Also set the level. This is not a programming module. The agent writes the composition code; the designer's job is the brief, the project structure decisions, and the review. Where code appears on slides it is there to be read, not memorised — the point is knowing what a healthy composition looks like when you review one.

Keep the model small: a Remotion project is a React app whose components receive a frame number instead of user events. The Composition declares the video's metadata — dimensions, frame rate, duration in frames — and points at a component. Inside that component, useCurrentFrame() returns which frame is being rendered, and helpers like interpolate() and spring() turn that number into the visual state for that instant. A 30-second clip at 30 fps is 900 evaluations of the same component.

Sequence is the structural primitive worth calling out for designers: it shifts a child component in time, so a video becomes a stack of scenes with explicit start frames and durations — readable structure, not a hidden timeline. That is what the agent edits when you ask for the second scene to start a second later.

Two facts to date-stamp. As of June 2026 Remotion's stable line is 4.x with a large ecosystem — studio preview, an embeddable player, templates, and official agent skills. And the frame-pure model has a cost: animation libraries that run on wall-clock time, GSAP being the common one, do not fit naturally; you describe motion in Remotion's own vocabulary. That trade-off is the seam the comparison later in the module runs along.

This slide is the maintainability argument. The first clip an agent produces will work almost regardless of structure. The fifth clip — the one where you change a product name across three videos, or re-skin everything after a brand refresh — only stays cheap if the project was structured for it. The structure is the same one designers already know from component libraries: one scene per file, named for its content; a root file that registers and sequences them; and content pulled out into props or a data file so a copy change is a data change, not an edit inside markup.

The tokens point matters most. If the compositions import colours, type, and spacing from the same token source as the product — or at minimum from one shared stylesheet — then a brand change propagates by re-rendering. If colours are hard-coded per scene, every video is a snapshot again, which is the exact failure code-defined video was supposed to remove.

The instruction-file point connects back to the harness material from earlier courses and Module 1: scene duration defaults, easing personality, reduced-motion behaviour, and the rule against inventing copy belong in the project's standing instructions, not in every brief. Remotion ships CLAUDE.md and AGENTS.md guidance in its own repository, and Hyperframes installs its skills into the project — both are signals that the frameworks expect this file to exist.

Hyperframes, published by HeyGen, is the lighter-weight answer for teams whose motion needs are real but small: short product clips, animated cards, looping walkthroughs. The composition is an ordinary HTML file. Elements carry data attributes that say when they appear and for how long; appearance is plain CSS; movement is a standard GSAP timeline created paused. The renderer's trick is the seek: before capturing each frame with headless Chrome it pauses the animation runtime and seeks it to that frame's exact time, which is what makes wall-clock libraries render frame-accurately — the thing Remotion's frame-pure model deliberately avoids needing.

The agent story is the strongest part of the pitch: the CLI is non-interactive by default, there is an installable skill pack that teaches the agent the framework's conventions, and lint and inspect commands give the agent checks it can run on its own output. As of June 2026 the project is pre-1.0 (0.6.x), Apache-2.0 licensed in the repository, requires Node 22 or later plus FFmpeg, and renders on a single machine — fine for clips, the wrong tool for thousands of personalised renders.

The phrase hyperframe-style in the module title is deliberate: even if the specific tool changes, the pattern — HTML as the composition format, timing in attributes, an existing animation runtime seeked per frame — is the durable idea, and it is the lowest floor for a designer who wants to read or hand-tweak a composition without learning React.

Walk the diagram column by column, then land on the shared band. Authoring: Remotion is React components where every frame is computed from the frame number; Hyperframes is plain HTML with timing in data attributes and no build step. Animation runtime: Remotion wants motion described in its own frame-pure helpers, interpolate and spring; Hyperframes pauses and seeks existing runtimes — GSAP, Lottie, Three.js, CSS — so the web's animation vocabulary carries over directly. Rendering: Remotion runs locally, server-side, or distributed across Lambda, which is a structural advantage at volume; Hyperframes drives headless Chrome and FFmpeg on one machine, which is fine for clips and not for personalisation at scale.

Then the fit lines: Remotion suits React teams, embedded players, and render volume; Hyperframes suits agent-first authoring, GSAP-heavy motion language, and lighter recurring clips. Neither line is a quality judgment.

Spend the most time on the shared band, because it is the reason this course exists: in both stacks the composition is diffable text in the repository, styled from design tokens, written by an agent that has loaded a skill pack, rendered with one command, and reviewed through the same gates as any other artifact. The MP4 is a build output. Choosing between the columns is a real decision; missing the shared band is missing the point.

The licensing row is the one most teams discover late, so spell it out. Remotion is not open source: it is source-available under its own licence, free for individuals, non-profits, and companies with up to three employees, and above that threshold a paid Company License applies — per-seat tiers for people working in the Studio and per-render pricing with a monthly minimum for automated rendering, as published on the official licence page as of June 2026. None of this is hidden, but the fact that npm install works leads teams to assume MIT-style terms, and that assumption fails exactly when adoption succeeds. Hyperframes' repository describes Apache 2.0 with no thresholds; it is owned by a commercial company and pre-1.0, so read the LICENSE file directly and re-check at upgrade time.

The maturity row cuts the other way. Remotion's 4.x line is stable, with hundreds of releases, a large ecosystem, and production users; Hyperframes is at 0.6.x and shipping rapidly, which means commands and behaviour can drift between versions — pin the version you build on. Both projects ship first-party agent support: Remotion documents agent prompting and publishes a skill pack, Hyperframes installs a set of skills and plugins built for non-interactive use.

Give the honest tie-breakers from the related article: React product, embedded previews, or render volume points to Remotion; HTML-and-GSAP motion language, designer prompt-writers, and cost sensitivity points to Hyperframes. Teams that cannot say which sentence describes them should build the same short clip in both — it takes an afternoon and settles it with evidence.

This is the module's centre of gravity for designers, because it is the part that does not transfer from the tools. A motion brief is a shot list with intent, not a prompt asking for something premium and dynamic. Each shot gets a start and end time, and the durations must sum to the clip's total — that arithmetic constraint alone removes a whole class of pacing drift. Each shot gets its on-screen text written out in full; the traced runs behind this course show that an agent asked to make it feel premium fills the screen with confident placeholder copy, and every word of it has to be corrected later anyway.

Hierarchy and emphasis are the parts a motion specialist would normally carry in their head, so write them down: what the viewer reads first, what supports it, what is allowed to move and what must hold still long enough to be read. Pacing rules can be crude and still work — a headline needs roughly a second per six words on screen before anything else demands attention.

Constraints close the brief: the easing personality from your motion system, reduced-motion behaviour, the rule that the agent never invents copy or statistics, and the instruction to run the project's checks before declaring the scene ready. Notice that nothing in this brief mentions Remotion or Hyperframes. That is deliberate — the same brief drives either stack, which is what makes the skill durable when the tools change.

The point of putting code on a slide in a design course is narrow: a designer reviewing motion work needs to be able to read the structure, not write it. Walk what is visible in each excerpt. In the Hyperframes version, the shot's duration and each element's entrance time are data attributes in the markup — the entire timing structure is readable without running anything — and the headline copy is right there to check against the brief. The motion itself lives in a GSAP timeline created paused, which is omitted here for space but is the same timeline a front-end developer would write for a landing page.

In the Remotion version, the same six seconds are expressed as frame arithmetic: the Sequence starts at frame zero and lasts six seconds' worth of frames, and the staggered reveal is two spring-driven transforms offset by a couple of frames. Same intent, different vocabulary. Neither is harder in any absolute sense; the question from the comparison slide — which vocabulary does your team already speak — is the one that matters.

What to take into your review habit: check the copy against the brief word for word, check that durations match the shot list, check that colours and type come from tokens or the shared stylesheet rather than hard-coded values, and be suspicious of any animation code that is registered but never advanced — that defect is covered properly two slides from now.

This slide extends the design-system discipline into the motion project, and the argument is economic. The whole case for code-defined video is that it stays current with the product. That only holds if the compositions consume the brand the same way the product does: colours and type from tokens or a shared theme stylesheet, logos and imagery from a named assets directory, music and voice files treated as versioned assets rather than email attachments. In the Hyperframes case the compositions can link the same CSS custom properties the marketing site uses; in Remotion the tokens arrive as imported constants or a theme object passed through props.

Motion tokens deserve their own line because they are the part teams forget: a small set of standard durations, easing curves, and stagger values, written into the project's instruction file, is what makes ten clips produced over six months feel like one brand rather than ten experiments. Module 4 builds the full motion system; here the point is just that the agent should be applying values, not inventing them per clip.

The templating point closes the loop: keep per-clip content — headlines, figures, product names — as props or composition variables so the same scene template serves many clips. The traced project behind the related article runs this way: the chapter videos and the short feature clips share templates and differ only in the variables fed in. That is the structure that makes the third video nearly free.

Reviewing motion has two layers, and teams new to this skip the first one. The composition review is a code-and-content review: does every on-screen word match the brief, do the durations match the shot list, do colours and type come from tokens, is there anything on the same track that overlaps. Both stacks give the agent checks it can run on its own output before you look — Hyperframes ships lint and inspect commands, and on the Remotion side the type checker plus a scrub through the Studio covers similar ground. Make running those checks part of the brief, not a favour you ask afterwards.

The frame review catches the failures that are invisible in code. The most instructive one from the project behind the related article is the dead animation: a GSAP timeline that is registered but never advanced, so the clip renders as a still image for its full duration. It passed code review and only showed up when early and late frames were actually compared — the project's audit found the defect in 8 of its 190 templates. That is why a frame-comparison step belongs in the gate, not just a play-through.

Then the judgment layer. Agents reliably produce motion that is technically correct and slightly too fast, because nothing in lint measures whether a human had time to read the headline. Pacing, emphasis, and whether the clip actually lands its message are human calls, the same way hierarchy and tone are in a UI review. Accessibility closes the list: reduced-motion behaviour, room for captions, and contrast at the final rendered size, checked before the expensive render rather than after.

For a single short clip on a laptop, the two stacks feel the same at render time: one command drives a headless browser and FFmpeg, and the result takes minutes rather than seconds. That is the practical reason the review gates sit before the render — iterate on lint output, inspected frames, and the hot-reload preview, render drafts at lower quality settings while the composition is still moving, and reserve the full-quality render for a composition that has already passed human review.

The stacks diverge at volume. Remotion's frame-pure model lets it split a render across many short-lived cloud functions with Lambda, which makes per-customer personalisation and large batches practical — and it is also exactly where the per-render pricing on the paid licence applies, so the teams that benefit most are the teams doing the maths on it. Hyperframes renders on one machine as of June 2026; for release clips and walkthroughs that is a non-issue, for thousands of personalised videos it is the wrong tool right now. Output formats follow the same pattern: both produce MP4; Remotion covers WebM, ProRes, GIF, and image sequences natively, while a Hyperframes pipeline typically adds an FFmpeg pass for anything beyond MP4 — the traced project also uses an FFmpeg pass to normalise resolution, a reminder that pre-1.0 tools have sharp edges worth pinning versions against.

Finally, destination discipline. Decide where the clip plays before briefing it — release notes page, social, in-product — because aspect ratio, resolution, captions, and file-size ceilings differ by destination, and retrofitting a 16:9 composition into a 9:16 cut is a redesign, not an export setting. The rendered file goes wherever your assets live; the composition stays in the repository as the thing your team maintains.

This trace comes from the first-party project documented in the school's motion article: a Hyperframes-based pipeline that turns written material into rendered explainer videos. Be transparent about its status the way the article is — the prompts, composition structure, and gate output are working material from that project, the iteration and time figures are labelled estimates reconstructed from its history rather than a fresh benchmark, and the render figures come from the project's existing local renders.

Walk the trace in order. The brief was written as a shot plan: an opening title card, two claim-plus-visual shots, a closing card, each with explicit durations and the on-screen words written out. The agent produced one composition file per shot plus a root timeline, and pulled colours and type from the project's existing theme stylesheet rather than inventing them — because the brief told it to and the project structure made the tokens findable. The first pass through the gates caught two real defects: a timing overlap that lint flagged, and a dead animation inherited from a library template, which only the frame-comparison audit caught — the same defect that audit had previously found in 8 of the project's 190 templates.

The numbers to leave people with: three composition passes and roughly an hour from brief to approved composition, a render measured in minutes, and an FFmpeg step in the pipeline to normalise resolution because the pinned pre-1.0 CLI rendered at double scale. Every correction in the trace was an edit to a text file. Nothing was fixed in a video editor, and that is the point of the whole module.

Keep the exercise to one scene, not a whole clip — the skill being practised is the brief, and one well-briefed scene teaches more than four vague ones. Steer participants towards a scene from a video their team genuinely keeps postponing: the title card of a release announcement, a single feature claim with a supporting visual, the closing call to action. The storyboard frame can be three rough rectangles on paper; its job is to force decisions about what is actually on screen, not to be drawable.

The parts people skip are the ones to insist on. Writing the on-screen text in full feels tedious and is the single biggest quality lever in the whole workflow. Setting durations that sum correctly forces the pacing conversation before the agent has the chance to default to too fast. The hierarchy line — read first, moves, holds still — is the design judgment the agent cannot supply.

If participants want to run the brief through an agent afterwards, the lowest-friction path is the hyperframe-style one from this module: install the skill pack, point the agent at the brief and the tokens, and ask for lint and frame inspection before any preview. But the exercise is complete without running anything. The brief is the artifact, and Module 3 picks it up: a narrated explainer is a sequence of exactly these scene briefs, hung off a script.

Recap along the structure of the module. The two stacks answer the same question with different materials: Remotion computes every frame from a frame number inside React components and scales its rendering further than anything else in this space; Hyperframes treats the composition as an HTML document, seeks existing animation runtimes frame by frame, and has the lowest floor for agent-first authoring. The licensing and maturity facts are the ones to re-verify on the day a team commits — they were accurate as of June 2026 and both projects move.

Then the parts that are stack-independent, because they are the durable skills: a project structured like a small design system, with scenes as components, content as data, and the brand arriving through tokens; briefs written in timing, hierarchy, emphasis, and exact words; reviews layered from automated checks through frame comparison to the human pacing pass; and rendering treated as the expensive final step that only approved compositions reach.

Preview Module 3 concretely. The next module changes the unit of work from a clip to a piece of communication: narrated explainers and decks generated from the same content source as the product or course material. The script becomes the primary artifact, slides and narration are produced from it rather than alongside it, and the editing pass keeps the result sounding like a person. The scene brief from this module's exercise becomes one beat of that script.