React provides a very elegant way to update the DOM by deriving it from your application's state.

Unfortunately how animations of UI elements should be done in this model isn't as clear and elegant yet (as far as I understand).

This GitHub repository shows one way of how animations could/can be done in React in a simple way.

React JS is a front end framework that understands how to render stuff (html) in real time reactively to changes in state. React does magic with the shadow DOM, the actual DOM, and diffs in order to minimize reflows and boilerplate. Probably the biggest downside to this approach is interacting with legacy JS animations because:

1. ReactJS owns the DOM it renders. The nodes in the DOM are subject to change or even disappear at any time. React allows for hooks, but will throw exceptions if a third party fucks with the DOM under its control too much.

2. ReactJS owns the data (state) that controls rendering. Moreover, the state tends to be buried inside some nested React Element. Ordinarily, we would move the state outside of react and just update the components when the state changes (per Flux guidelines), but this is quite awkward when the state is for something like pixel offsets of a DOM node or some intermediate step in an animation- the component that does the rendering should own this information conceptually.

CSS animations tend to suck in practice- they aren't very flexible and they can't be controlled from JS (they go until completion). Existing JS frameworks for animations (eg JQueryUI) cause as much trouble as they provide solutions. The new library provides the correct solution- control animations from within React Elements themselves via a React Mixin.