> Again...WTF does that even mean? So they only use CSS3 transforms that are GPU accelerated? So it's a CSS3 animation library? The vague documentation seems to

> Again...WTF does that even mean? So they only use CSS3 transforms that are GPU accelerated? So it's a CSS3 animation library? The vague documentation seems to imply a grander vision which is unclear. The core of Famo.us is a rendering engine. Instead of using the DOM to represent its UI hierarchy or using the browser to render that hierarchical DOM to screen, it uses an internal scene graph representation and handles the rendering of the scene graph to screen through an abstracted output layer. The browser DOM is just one of its supported outputs; another is WebGL, and there's no reason there couldn't be other outputs, outside of the browser--I think this extensibility is part of the 'grander vision.' The scene graph is a very robust graphics model, so it would be a great choice for a model if someone were to reinvent HTML from scratch today. Again, 'grander vision,' maybe. In the case of rendering to the browser, the way it works is by flattening and compositing its scene graph, creating a DOM node for each 'Surface' (which is a leaf node of the Famo.us scene graph) and handling the 3-space (or really, 2.5-space) positioning with CSS3 Matrix3D transforms, which are GPU accelerated. Since the DOM isn't needed for hierarchy (again, all of the calculations are handled by the engine) the Famo.us-outputted DOM is a simplified set of sibling nodes underneath a single parent (the Famo.us container,) and it continuously updates the Surfaces' DOM representations' Matrix3D properties (performantly, leveraging requestAnimationFrame) as the scene graph gets updated by the program running on the Famo.us engine. So that's pretty much what Famo.us is. Does that help? A slightly less technical, if more practical explanation might be about how you can "write one JS app [and] deploy everywhere with awesome performance across devices and browsers."