Pitfalls & Gotchas

Famo.us does its best to provide a rich visual experience at 60 FPS. However, some techniques that are commonplace in traditional web development can have a negative impact on Famo.us’ performance. Here, we’ll cover a few of the main techniques to avoid so that your application will keep humming.

Pinging the DOM

Famo.us is very different from many Javascript frameworks, since it endorses zero touches to the DOM. Querying the DOM (selecting elements, querying an element property) can lead to both performance issues as well as unexpected behavior.

In terms of performance, invoking large queries against the DOM is fairly expensive (in measurement of CPU cycles). Also, seemingly simple requests, such as asking for the width of a DOM element, will sometimes cause the entire page to reflow in order to calculate the correct value for the element’s width. These reflows are made more apparent in a highly animated environment.

When pinging the DOM, unexpected behavior can also arise because of how Famo.us uses DOM elements. Some Famo.us components, such as Scrollview, can cause the DOM element associated with a surface to be deallocated. This resource pooling optimization allows Famo.us to minimize the amount of DOM element creations (an expensive operation). However, this leads to issues when trying to access DOM elements that no longer are present in the DOM.

Using setInterval, setTimeout, etc.

Using the default Javascript .setInterval() timer function will cause issues in Famo.us because of the amount of code the engine runs. In some cases, it is even possible for the default .setInterval() to miss a cycle. If you need .setInterval()- or .setTimeout()-type functionality, use Famo.us’ Timer utility instead:

var Timer = famous.utilities.Timer;
Timer.setTimeout(function(){ /*...*/ }, 100);
Timer.setInterval(function(){ /*...*/ }, 100);

Using native DOM events

Using native DOM events is fine for intra-surface eventing but is messy for inter-surface eventing. When trying to communicate across surfaces, it is best to use Famo.us’ own eventing system. By keeping all events in a single system, your application will be much easier to manage.

Also, because of the resource pooling (mentioned above in the section in Pinging the DOM), it is possible that your surface may have its DOM element deallocated — resulting in a loss of all of the registered DOM event handlers that were registered on it.

Non-performant CSS

CSS is from the age of web pages, not web applications. As a result, the long paint and reflow times associated with certain CSS classes has gone somewhat unnoticed due to the static nature of the web. Below are some of the CSS pitfalls a developer may run into in a highly dynamic environment:

Combining border-radius and box-shadow: Try to avoid this technique as it will lead to performance problems, especially during animations. See the CSS Paint Times and Page Render Weight for a great explanation.
Breaking the bounding box. Using CSS to position child elements outside of the bounding box of their parent will lead to performance issues. While it is common to see DOM elements absolutely positioned, e.g. left: -5px, in the wild, this technique actually makes it harder for browsers to paint the element performantly.
Transitioning color values: This causes large amounts of repainting and is very non-performant. To achieve a similar effect, try stacking a handful of <canvas> or <div> elements of different colors and, then opacitate them in/out accordingly. (Be careful not to add too many layers, as there is also a performance hit when too many surfaces exist on the screen.

Check out High Performance Animations for a great rundown of CSS’ impact on performance.