Motion v2 — spring & gesture animation
Not started. v1 (Rust-owned transition={{ duration }} for opacity) is shipped. This page is about the bigger,
separate ambition: actual Framer Motion parity.
Two different products hide under "animation library," and only the smaller one exists today:
- CSS
transitionparity (v1, shipped) — a style prop changes, the framework interpolates instead of snapping. Covers "things popping instead of animating." See the Animations guide. - Framer-Motion-style spring/gesture animation (v2, this page) —
useAnimatedValue, drag-to-dismiss, staggered entrance/exit for lists, physics-based springs driven by gesture input. A meaningfully bigger, separate initiative — not scoped in detail yet.
Architecture direction
Not scoped in detail, but the v1 decision — Rust owns the interpolation, JS declares intent only — is expected to carry forward rather than get revisited: a JS-driven per-frame animation loop pays an FFI-crossing cost every frame, which matters more now that QuickJS (no JIT) is a first-class target, not just V8. The open questions for v2 are less about "where does the loop live" (Rust, settled) and more about the API shape — a full expression DSL vs. a fixed set of spring/gesture primitives — and how gesture input (drag, swipe) feeds into it without JS re-entry per frame.
If gesture-driven animation is blocking something you're building, open an issue or start a discussion on GitHub (opens in a new tab) — this is prioritized by what people are actually building, same as the rest of the roadmap.