Hi HyperFrames team,
I want to propose a new optional package: a Manim-style math animation layer, maybe @hyperframes/math or @hyperframes/manim.
HyperFrames already does the hard parts of a browser-native Manim alternative. It renders deterministic video from HTML, supports seekable animation, and has adapters for GSAP, CSS, Lottie, Three.js, Anime.js, WAAPI, D3, and custom runtimes. A math animation layer built on SVG, Canvas, or WebGL would sit neatly on top of that.
What Manim gets right is that authors work with mathematical objects, not just moving DOM nodes: equations, graphs, axes, vectors, curves, matrices, transformations, proofs. HyperFrames already handles the other half: previewing and rendering videos from web-native compositions.
This would open up HyperFrames for:
- math, ML, physics, and algorithm explainers
- animated derivations and proofs
- calculus and linear algebra visualizations
- model architecture diagrams
- educational shorts generated by agents
- research demos where the final artifact is still plain inspectable HTML
It also fits the agent-first direction. Agents can already write HTML and scripts. A small, well-designed math API is easier for them to use than hand-authoring SVG paths and timelines every time.
Possible shape
The package could live outside core at first:
packages/math/
src/
scene.ts
mobjects/
circle.ts
line.ts
axes.ts
graph.ts
tex.ts
matrix.ts
vector.ts
animations/
create.ts
write.ts
transform.ts
moveAlongPath.ts
indicate.ts
renderers/
svg.ts
canvas.ts
adapter/
hfmath.tsThe user-facing API could look like this:
<div
id="stage"
data-composition-id="math-demo"
data-start="0"
data-width="1920"
data-height="1080"
>
<svg id="math" width="1920" height="1080"></svg>
<script type="module">
import {
HFMathScene,
Axes,
Graph,
Dot,
Tex,
Create,
Write,
MoveAlongPath,
TransformMatchingTex,
} from "@hyperframes/math";
const scene = new HFMathScene("#math", {
width: 1920,
height: 1080,
duration: 8,
});
const axes = new Axes({ xRange: [-6, 6], yRange: [-2, 2] });
const sine = new Graph((x) => Math.sin(x), { xRange: [-6, 6] });
const dot = new Dot();
const eq1 = new Tex("y = \\sin(x)");
const eq2 = new Tex("\\frac{dy}{dx} = \\cos(x)");
scene.play(Create(axes), { duration: 1 });
scene.play(Create(sine), { duration: 1.5 });
scene.play(MoveAlongPath(dot, sine), { duration: 2 });
scene.play(Write(eq1), { duration: 1 });
scene.play(TransformMatchingTex(eq1, eq2), { duration: 1.5 });
window.__hfMathScenes = { "math-demo": scene };
</script>
</div>HyperFrames would still do what it does well: seek the page and render frames. The math scene would make sure scene.seek(time) draws the right mathematical state for that frame.
Runtime integration
This could plug into the existing deterministic adapter model without touching the renderer:
export function createHFMathAdapter(): RuntimeDeterministicAdapter {
let scenes: HFMathScene[] = [];
return {
name: "hfmath",
discover() {
scenes = Object.values(window.__hfMathScenes ?? {});
},
seek({ time }) {
for (const scene of scenes) scene.seek(time);
},
pause() {
for (const scene of scenes) scene.pause?.();
},
getInferredDurationSeconds() {
return Math.max(...scenes.map((s) => s.duration()), 0) || null;
},
getReadyPromise() {
return Promise.all(scenes.map((s) => s.ready?.())).then(() => {});
},
};
}That keeps it compatible with deterministic rendering and avoids requestAnimationFrame, Date.now(), or other non-seekable state.
Core primitives
The first useful version does not need to be huge. A small MVP could include:
Objects:
LineArrowDotCircleAxesNumberLineGraphParametricCurveTexTextMatrixVector
Animations:
CreateWriteFadeInFadeOutTransformReplacementTransformTransformMatchingTexMoveAlongPathIndicateApplyFunction
For Create, SVG stroke reveal with stroke-dasharray and stroke-dashoffset would be enough. For Transform, paths could be flattened and resampled into a fixed number of points, then interpolated. For TransformMatchingTex, the MVP could start with token-level matching and later move toward MathML or glyph-level matching.
Why SVG first
SVG is the best first renderer because it is inspectable, agent-friendly, and maps well to math objects. It also works naturally inside an HTML composition. Canvas or WebGL can come later for heavy scenes, vector fields, particle systems, or large graph animations.
Agent skill idea
This could ship with a skill like /hyperframes-math.
The skill would tell agents when to use the math API instead of raw div animations: theorem explanations, equation derivations, graph animations, calculus scenes, linear algebra, ML architecture diagrams, and research-paper explainers.
That would make the library useful not only for human authors, but also for the agent workflows HyperFrames is already designed around.
Example demos
- derivative as tangent line
- Riemann sum becoming an integral
- gradient descent moving on a loss curve
- eigenvectors under a linear transformation
- Fourier series approximation
- attention mechanism explanation
- backpropagation chain rule visualization
- transformer architecture walkthrough with equations
HyperFrames already has the rendering and production loop. Manim proved people want high-level math animation primitives. The missing piece is a browser-native, agent-friendly version that produces deterministic MP4s from inspectable HTML. A focused @hyperframes/math package could fill that gap without weighing down the core renderer. It can start as an optional package and a few examples, then grow based on what people actually build.
If this direction sounds interesting, I can help sketch the API or put together a small prototype.
Hi HyperFrames team,
I want to propose a new optional package: a Manim-style math animation layer, maybe
@hyperframes/mathor@hyperframes/manim.HyperFrames already does the hard parts of a browser-native Manim alternative. It renders deterministic video from HTML, supports seekable animation, and has adapters for GSAP, CSS, Lottie, Three.js, Anime.js, WAAPI, D3, and custom runtimes. A math animation layer built on SVG, Canvas, or WebGL would sit neatly on top of that.
What Manim gets right is that authors work with mathematical objects, not just moving DOM nodes: equations, graphs, axes, vectors, curves, matrices, transformations, proofs. HyperFrames already handles the other half: previewing and rendering videos from web-native compositions.
This would open up HyperFrames for:
It also fits the agent-first direction. Agents can already write HTML and scripts. A small, well-designed math API is easier for them to use than hand-authoring SVG paths and timelines every time.
Possible shape
The package could live outside core at first:
packages/math/ src/ scene.ts mobjects/ circle.ts line.ts axes.ts graph.ts tex.ts matrix.ts vector.ts animations/ create.ts write.ts transform.ts moveAlongPath.ts indicate.ts renderers/ svg.ts canvas.ts adapter/ hfmath.tsThe user-facing API could look like this:
HyperFrames would still do what it does well: seek the page and render frames. The math scene would make sure
scene.seek(time)draws the right mathematical state for that frame.Runtime integration
This could plug into the existing deterministic adapter model without touching the renderer:
That keeps it compatible with deterministic rendering and avoids
requestAnimationFrame,Date.now(), or other non-seekable state.Core primitives
The first useful version does not need to be huge. A small MVP could include:
Objects:
LineArrowDotCircleAxesNumberLineGraphParametricCurveTexTextMatrixVectorAnimations:
CreateWriteFadeInFadeOutTransformReplacementTransformTransformMatchingTexMoveAlongPathIndicateApplyFunctionFor
Create, SVG stroke reveal withstroke-dasharrayandstroke-dashoffsetwould be enough. ForTransform, paths could be flattened and resampled into a fixed number of points, then interpolated. ForTransformMatchingTex, the MVP could start with token-level matching and later move toward MathML or glyph-level matching.Why SVG first
SVG is the best first renderer because it is inspectable, agent-friendly, and maps well to math objects. It also works naturally inside an HTML composition. Canvas or WebGL can come later for heavy scenes, vector fields, particle systems, or large graph animations.
Agent skill idea
This could ship with a skill like
/hyperframes-math.The skill would tell agents when to use the math API instead of raw div animations: theorem explanations, equation derivations, graph animations, calculus scenes, linear algebra, ML architecture diagrams, and research-paper explainers.
That would make the library useful not only for human authors, but also for the agent workflows HyperFrames is already designed around.
Example demos
HyperFrames already has the rendering and production loop. Manim proved people want high-level math animation primitives. The missing piece is a browser-native, agent-friendly version that produces deterministic MP4s from inspectable HTML. A focused
@hyperframes/mathpackage could fill that gap without weighing down the core renderer. It can start as an optional package and a few examples, then grow based on what people actually build.If this direction sounds interesting, I can help sketch the API or put together a small prototype.