Shane O'Sullivan's technical blog… really ties the room together

Edgeconf 2013 Web Performance Panel

Posted by Shane O'Sullivan on February 12, 2013

Edgeconf 2012 Web Performance Panel

I had a great time at Edgeconf, taking part in the Web Performance panel. We got to discuss many of the common issues that web developers face when building complex web apps, such as avoiding reflow, repaints and avoiding garbage collection.

The full video is available now HERE.

The slides are available here

All other panel videos are available HERE, or will be soon if not yet uploaded.


Posted in Technical | Tagged: , | Leave a Comment »

Click, change then animate: My self imposed rule for a fast & smooth UI

Posted by Shane O'Sullivan on October 14, 2012

A few months ago I joined the Ads Interfaces team at Facebook, after almost two years on the mobile team, and am very proud of being part of the group that shipped a full rewrite of the Ads Create Flow ( last week.  The application is highly complex, with many varying user interface elements, lots of data floating around, validations and so forth, so it made sense to write it 100% client side in JavaScript. 

In many ways it’s a standard MVC application with

  • declarative view definitions, so you can easily relate the code to what you see in the Web Inspector
  • well defined data models which can be observed for changes
  • bidirectional bindings between views and models to keep the UI in sync with the data.  That is, if a piece of data changes, the UI should just update itself.  Of course, it is also possible to add code in between any binding if some more complex processing is needed.  For example, when changing the top level objective (clicking one of the huge buttons), I wanted it to animate the change, so rather the transference of the data update is delayed.

My New Rule

One of the primary lessons I took away from this is that asynchronous data fetching is one of the leading causes of users feeling like a UI is “webby”.  That feeling where the interface suddenly, with a jerk, jumps around and changes size.

This is often caused by images loading, or by an API call returning, resulting in the UI being redrawn.

I decided on a new rule to apply to interfaces I work on:

The UI can change suddenly when the user interacts with it.  All other changes should be smooth.

What this means is if the user clicks a link or a button, it’s OK to immediately change the UI, since they can see the causation.  However if new data comes back, or a large image loads shifting the entire UI up or down, this should be smoothly animated. 

I’ve found that this both gives an interface a more polished feel, but also draws the users eye to important information.  In addition, if they were already reading something, trying to make a choice of what to click next, if that jumps even a couple of centimeters they have to start searching for it again – it may have gone below the bottom of the screen.  However if it smoothly moves there over 300ms, they continue without much interruption.

It’s important to not go overboard with this of course.  Don’t animate everything, as it’ll feel gratuitous.  I’ve found that sticking to animating only asynchronous operations leads to an application feeling both fast and professional.


Some examples in the Ads Create Flow are the large image that loads for Sponsored Stories (the bottom picture), and the entire Ad preview that loads as a result of a data callback (under Right Hand Column Preview).


One caveat is that on IE 8 & 9, you’re going to have a bad time.  I chose to not bother with janky timer based animation solutions, both in the interest of saving time, and from a healthy disdain for legacy browsers.  So, I advise to stick with CSS3 animations, and let the users of old browsers have a working but less attractive application. 

Posted in Facebook, HTML5, Internet Explorer, Javascript, Technical | 4 Comments »

What Git branch was I working on again?

Posted by Shane O'Sullivan on June 16, 2012

A situation I often find myself is remembering what Git branch I was working a few hours ago.  Partially this is my own fault, since I tend to name Git branches after task IDs, e.g. “12345”, in order to easily find them, but also just my brain has limited space and can’t remember more than three things at any one time.

A useful command I’ve found (for the Mac and probably Linux) is the following

for k in `git branch|perl -pe s/^..//`;do echo -e `git show --pretty=format:"%Cgreen%ci %Cblue%cr%Creset" $k|head -n 1`\\t$k;done|sort -r

This prints out a list of your branches, and the length of time since you last checked them out.  It makes it really easy to find that unmemorable branch.

Of course, it’s easier if you put that command in a reusable function, e.g.

function listGitBranchesByMod() {
    for k in `git branch|perl -pe s/^..//`;do echo -e `git show --pretty=format:"%Cgreen%ci %Cblue%cr%Creset" $k|head -n 1`\\t$k;done|sort -r

inside some *.sh file on your PATH.

I found this somewhere on the web, and cannot find it again. If it was you, please let me know so I can link to the original. Oh, and thanks!

Posted in Technical | Tagged: , | Leave a Comment »

Caching Events in Mobile Safari is a bad idea

Posted by Shane O'Sullivan on May 3, 2012

A recent issue with JavaScript devlopment that I’ve come across on Mobile Safari (note: not desktop Safari) is that if you add an event listener to a DOM node and for whatever reason keep a reference to the Event object you receive, you’ll run into errors.

This is because the same Event object is reused,  with its properties being updated every time.  I presume this is to conserve memory on mobile devices, as it is both in short supply and causes too much garbage collection, the enemy of responsive UIs.

The simple solution is, rather than caching the Event object (a bad idea any as it prevents it being garbage collected on other platforms), take what information you need from it, such as touch coordinates, and cache those instead.

Posted in Javascript, Technical | Leave a Comment »

Dynamically change deviceDpi on iOS

Posted by Shane O'Sullivan on December 13, 2011

When Apple released the iPhone 4 with a retina display, they quadrupled the pixel density.  This caused problems for websites, as all their assets would now look tiny.  To solve this, Apple made it so that websites would keep the old low density rather than the retina display, and would allow sites to opt in to using the hi-res display.

This is done by adding a <meta> tag to the header, like

  <meta name=”viewport” content=”initial-scale=0.5,maximum-scale=0.5,user-scalable=no,width=device-width,height=device-height,target-densityDpi=device-dpi” />

Note the 0.5 for the scale values.  This resizes the screen to take advantage of the full retina display.  Pretty.  To use the low-res version, the scale parameters are 1.

However, if you’re writing a static HTML based web app, with no backend, you can’t go sniffing the user agent to figure out whether to set the scale to 0.5 or 1 before generating the page, so you’ll have to do it in JavaScript.


Here’s a simple script to do that, from my colleagues on the JSGameBench project at Facebook.  To use this, first put the meta tag above into the <head> of your document, with scale values of 1.

  if (window == {
        var meta_viewport = document.querySelector &&
        if (meta_viewport && window.devicePixelRatio >= 2 ) {
          meta_viewport.setAttribute(‘content’, ‘user-scalable=no, width=device-width, height=device-height, initial-scale=0.5, maximum-scale=0.5’);

The script looks for the meta tag, checks if you have a hi-res Apple display, and switches the device screen scale to use all the pixels, not just one in four.

One more thing…..

If your web app uses CSS like

html, body {
  width: 100%;
  height: 100%;

to fit the app to the screen dimensions, and inside perhaps you have some JS based scroller, then you’ll need two further lines.  The script then becomes

if (window == {
  var meta_viewport = document.querySelector &&

  if (meta_viewport && window.devicePixelRatio >= 2 ) {
    meta_viewport.setAttribute(‘content’, ‘user-scalable=no, width=device-width, height=device-height, initial-scale=0.5, maximum-scale=0.5’); = ‘200%’; = ‘200%’;

Without these extra lines, the page will only occupy one quarter of the screen, rather than all of it.

Now you have an app that looks right on older iOS devices, but still uses the hi-res screen of the iPhone4 for really sharp fonts and more.


Make sure that when designing your borders and other screen elements to use multiples of two.  E.g. have your borders be 2px, not 3px, so that when the phone divides them by two it’ll look right.

Posted in Technical | Leave a Comment »

Tracking memory usage on WebOS with GnuPlot

Posted by Shane O'Sullivan on October 16, 2011

I’ve been fighting against a serious memory leak in a WebOS app I’m developing, and unfortunately the tools available for WebOS are no help whatsoever for these kinds of problems. There is a program available for WebOS called JsTop, but the data that it tracks doesn’t show that my app is using lots of memory, while at the same time the Touchpad is crashing with the infamous “Too Many Cards” error, with just one card on the screen.

So, I decided to see what I can do about it. A little fiddling with novaterm, grep, awk and GnuPlot has helped me a lot, and hopefully it can help you too.

The image above shows the percentage memory (red) and CPU (green) usage over time of the WebAppMgr process in WebOS, which is essentially where all the apps are executed.  To get a graph like this, download the following two scripts (Mac/Linux/Cygwin only): [Source]

You’ll probably have to make them executable, so do:

chmod +x
chmod +x

Then plug in your WebOS phone or TouchPad via USB, and run


and you should see a graph like the one above.  If you don’t see it, it’s likely that you don’t have GnuPlot installed, so Google how to do that for your system, it should be trivial.

For what it’s worth, I get a “Too Many Cards” error just before the process hits 60%, meaning that the other running processes are taking up the remaining ~40% of memory.

If you feel like playing around with this script and doing something else cool, let me know!

Posted in performance, WebOS | 3 Comments »

How to easily check a WebOS app version

Posted by Shane O'Sullivan on October 7, 2011

If you’re a WebOS developer and would like to be able to notify your users when a new version of your app is available, a very efficient way to do that is to use the Yahoo Query Language.

Take a look at this page:

It shows a YQL query to select the version of the app com.chofter.palmdevutils, giving the following result

 "query": {
  "count": 1,
  "created": "2011-10-07T14:58:53Z",
  "lang": "en-US",
  "results": {
   "p": "Version: 1.3.0"

Fetching this JSON object requires far less data that reading the entire HTML page and parsing it yourself. To see the final link that you would use, copy the link from the bottom of the Yahoo page, like this one*’%2F%2Fdiv%5B%40id%3D%22app-price-system-version%22%5D%2Fp%5B3%5D’&format=json&callback=

Posted in Javascript, WebOS, yql | 1 Comment »

JavaScript performance tips

Posted by Shane O'Sullivan on September 28, 2011

Every now and again a question comes up at work as to which of two or more approaches to the same problem in JavaScript performs better. I’ve started using the fantastic site to document these, so I’ll append to this post whenever I add a new test. I hope you find these useful, as they are answering questions that pertain to practical JavaScript usage.

Creating a regex inside and outside a loop

Declaring variables in a loop or outside it

Using hasOwnProperty or testing with undefined and void 0

Using indexOf or substring to test the end of a string

Extend Without Foreach

Posted in Javascript, performance | 1 Comment »

Tip: Declare regular expressions once and reuse for performance win

Posted by Shane O'Sullivan on September 22, 2011

A pattern I see quite often in JavaScript is of people using a regular expression in a loop, e.g.


for (var i = 0; i < array.length; i++) {

The naive assumption is that a regex is some special native thing, like a boolean. However regular expressions have a cost to construct, which you can see in this performance test –

So, if you’re using a regular expression in JavaScript more than once, declare it first and reuse it to see a dramatic performance gain

Posted in Javascript | 3 Comments »

CSS Box Sizing makes me happy

Posted by Shane O'Sullivan on September 13, 2011

Quick note: For anyone fighting for years against the CSS box model, where the visible size of an element depends on the sum of it’s width, height AND padding, check out the box-sizing: border-box;. It does exactly what we need, where if you say

.myclass {
width: 100%;
padding: 10px;

then myclass will still take up 100% width of its container, instead of overflowing.

Posted in Technical | Leave a Comment »

%d bloggers like this: