That's very sad! React-Move may implement very simple animation "concepts" that you could perform on your own, but there is immense value in the reusable API th

That's very sad! React-Move may implement very simple animation "concepts" that you could perform on your own, but there is immense value in the reusable API that React-Move exposes. If you were to utilize d3-interpolate, or a tweening library directly, you would still need to: handle proper react-lifecycle updates, animation-frame batching, detect when to reanimate, provide a deterministic and reusable api that promotes good composition, support as much of the ecosystem as possible, and at the same time keep dependencies and component footprint as small as possible. React-Move provides all of these things in a battle tested package that, given its rapid growth, has already proved its suitability for the majority use-case and general animation needs of React users. On the topic of hardware acceleration, there are a some good perks to using class-based/keyframe CSS animation, but you immediately forfeit any ability to utilize dynamic run-time values. It's also important to note that even though React-Move's animation loop is being executed in Javascript instead of the browser's GPU thread, doesn't mean React-Move doesn't utilize hardware acceleration. By mapping these interpolated values to hardware-accelerated css properties, you are in fact using hardware-accelerated transitions, albeit at the speed of the JS thread. If all of these amazing features aren't your cup of tea, then I would most definitely suggest that you roll your own solution. :) Cheers!