One of the major benefits of helping to organize a workshop for a new JavaScript framework is the obligation and privilege of attending.
It was definitely a privilege to attend the May 22 “Get to Know Famo.us” session, an introduction to the recently open sourced Famo.us.
Led by Connor Turland, lead developer at metamaps.cc, the workshop began with a quick review of the framework’s history. Famo.us was originally announced to the public at TechCrunch Disrupt 2012 but only made available to the general public a few weeks ago.
The framework’s claim to fame is that it enables native-like, 60fps rendering for browser-based applications written in JavaScript. It does this by bypassing the most significant bottleneck in classic browser layout engines, interacting with the DOM. Websites built with Famo.us have an extremely flat DOM because, from a programmer’s point of view, Famo.us replaces the DOM with its Render Tree.
Like the DOM, the Render Tree is a tree, but nodes in a Render Tree are not HTML Elements; they are Renderables or Modifiers.
In less than 40 minutes, Connor had the room full of developers up to speed on the core concepts and ready to write some code. We started by creating our own Surfaces, one of the two types of Renderable nodes. Everything in an application that gets displayed is contained in a Surface. For example, if you were to render a deck of cards, each card would be its own Surface. From a modern web development point of view, every time you would be inclined to create a container div or other block element, you are probably interested in creating a Surface.
There are many different types of Surfaces, including Image, Video and InputSurface, each of which corresponds to standard HTML tags such as <img>, <video> and <input>.
The other type of node in Famo.us is a Modifier. Modifiers are responsible for layout and visibility, whereas Surfaces simply store content. In the classic structure-appearance-behaviour triad of HTML, CSS and JavaScript Surfaces are for structure and Modifiers are for appearance and behaviour. To my mind, this very nicely addresses the increasingly blurred lines between CSS and JavaScript as well as taking advantage of the direct access to the GPU browsers offer to CSS transforms.
Interface elements are added to the Render Tree as combinations of Modifers and Surfaces. Any appearance or behaviour rules described by a Modifer affect any descendants of that Modifer. Complex behaviours are created as a hierarchy of Modifiers whose rules compound to affect the Surface nodes below them in the tree.
The last major piece of the workshop was assembling a collection of Views to create the application interface’s structure. Views are self-contained trees containing a collection of Modifiers and Surfaces that combine to make specific behaviours. Views can be created by developers, or we can take advantage of the small but rapidly growing library of common views created by Famo.us and the community.
I am a total web nerd at heart, but I’ve been lucky enough to participate in the development of several native applications and I deeply enjoy the conventions all platforms (mobile or desktop) embrace around assembling Views of different sorts - ListViews, ScrollViews, TabViews, NavigationViews, etc, - to allow for rapid interface development.
Famo.us embraces these conventions. They aren’t the only front-end library to do so, but to me this is a really good idea. Anyone with a moderate amount of exposure to these conventions, through native development or elsewhere, is going to feel very comfortable with Famo.us.
Rob Drimmie is a lucky man. He has an amazing wife and two awesome boys. He is a developer of software, talent and community through his work at Communitech and participation in local events for developers and entrepreneurs.
