Note that the translation parameters include values for the x, y, and z axes. Also note that chained modifiers apply from right to left: mainContext.add(stateModifier).add(modifiedSurface) means that modifiedSurface has stateModifier, defined as Transform.translate(150, 100, 0), applied before it is added to mainContext and displayed.
Famo.us uses matrix3d WebKit transforms on <div> elements with absolute positions rather than using a conventional nested DOM tree in which child elements are positioned relative to their parent elements. Famo.us gains performance by using the hardware-accelerated matrix3d WebKit transforms and avoiding the relatively slow layout flow calculations of a typical HTML5 page.
Overall, the way Famo.us does transforms and rendering feels a lot more like the way console games do their graphics than the way Web browsers normally work.
Lesson 2 goes on to explain chaining modifiers and applying rotations. As you probably remember from your high school analytic geometry, a translation followed by a rotation will give you different results than a rotation followed by a translation.
As discussed earlier, chaining is applied right to left, so mainContext.add(translateMod).add(rotateMod).add(surface) adds the surface to the main context, rotates it Pi/4 radians (45 degrees), and translates it down 100 pixels and to the right 100 pixels.
Reversing the order — mainContext.add(rotateMod).add(translateMod).add(surface), for example — would give us a rectangle cut off at the left:
Famo.us Render Tree
As we discussed earlier, Famo.us uses matrix3d WebKit transforms on <div> elements with absolute positions rather than using a conventional nested DOM tree in which child elements are positioned relative to their parent elements.
The Render Tree has two types of nodes: renderables, such as a Surface, and modifiers, which are responsible for the layout and visibility of the Render Tree below them. Modifiers can be chained, as I mentioned earlier.
In Famo.us, views are encapsulations of groups of renderables and modifiers that you wish to hide from the master Render Tree. Views are typically what a Unix UI developer would call a widget, but implemented as a Famo.us RenderNode paired with an input EventHandler and an output EventHandler. The views in the Famous Example repository as of this writing are Deck, EdgeSwapper, GridLayout, HeaderFooterLayout, RenderController, Scrollview, and SequentialLayout. The expectation is that you'll subclass views to extend and customize them into your own widgets, or write your own renderable items from more basic components.
Sign up for CIO Asia eNewsletters.