(By the way, we’re on Discord!)
I get very happy each time someone pings me on Twitter to show a crazy new React-Motion demo. As a library maintainer, that’s really what I hoped for! Furthermore, talking to the community and sitting in the Slack channel informed me about people’s pain points and confusions. In particular, one question that comes back often is where React-Motion stands compared to Animated, and vice-versa. I’d like to clear up this misconception here.
“Animation” is a loaded term. When we say “animate this item in React”, we might be talking about:
- Interpolating a certain property on the item.
- Managing the animation timeline.
- Chaining the item with many others (e.g. staggering).
- Do an animation before unmounting.
- Animating the child through layers of abstractions (components).
- Animate the item cross-views.
- etc.
Traditional animation libraries, such as the excellent Velocity.js and GreenSock, are mostly focused on the first two/three points. The new Animated for React-Native and React web achieves the same goal well, while catering to React’s idioms.
However, the last few points are less understood when people ask about animation in React. These are what React-Motion is set to solve. The fact that it also does e.g. interpolation is simply because, well, otherwise you wouldn’t see the animated result. How does one animate an item upon unmounting? The item isn’t even present on the next render anymore! Animated’s goal is to provide a good API for transitioning, not to solve, say, unmounting animation, because it’s technically not an animation problem, and is (currently) React-specific. In that regard, asking whether one should use Animated or React-Motion is generally a false dichotomy.
What Can React-Motion Do, Really?
I’ll skip writing about what Animated does, since 1. interpolation is well-understood already and 2. you can trust Facebook’s engineering chops at releasing battle-tested libraries and squeezing out every last bit of that perf juice.
React-Motion (RM) does interpolation and is not too shabby at it; but again, it’s a necessary setup for accomplishing the last few points mentioned above. I’ve set out to replace TransitionGroup with RM’s TransitionSpring; so far it’s been going pretty darn well. Check out the work of Twitter users:
Unmounting animation on arbitrary render shape, de-unmountable animation, animation through many abstraction layers… you get the idea. Let’s end this section with a brief question: how would you transition a half-finished animation (conserving velocity) over to another sibling view? This is the kind of problem RM is trying to solve.
(One more thing: https://github.com/chenglou/react-motion#demos)
Animated Is Great
That being said, Animated is really good at interpolating stuff. There’s no reason for RM to keep its interpolation logic if we can defer to using Animated under the hood. In the future, if everything goes according to plan, RM will use Animated for the actual interpolation and efficient DOM manipulation (like I said in my React-Europe talk, I’d rather have no animation than choppy/uninterruptible animation), or vice-versa. Which means we can merge the two libraries into one. We can also optionally provide hooks to swap out the interpolation engine for, say, Velocity or GreenSock, or other rendering targets such as React-Canvas (RM currently Just Works ™ on canvas through re-rendering the component; for perf reasons we’ll default to not doing that and let other rendering targets perform the animating part more efficiently).
Thank you!
The React community has gathered together to solve some hard problems, and some problems that have only recently been revealed as hard. A part of the goal of RM is to surface those. With Animated as a solid foundation for the interpolations and sequencing, and React-Motion’s coordination model, we’re looking forward to a pretty bright future for UI interactivity =).
