Tag: Web Development

ES6 Feature Performance

by on Jun.25, 2015, under Dev

Update: The results below are a snapshot from when this post was written. kpdecker.github.io/six-speed/ has the most recent results.

With ES6 features landing quickly in native browsers and readily available for use through Babel and Traceur, it seemed like it was time to look not just at support, but also the performance impact of using these features under the current implementations.

While there is great promise for the future, the picture of ES6 feature performance today is very muddled and depends on the specific feature being used. Some such as bindings and simple arrow/destructuring are ready for use today, others such as generators and tagged template strings might require analysis before using.

The standard warnings of premature optimization and recommendations to profile your own code apply to the comments here. These tests are very micro in their scope and might not be representative of your particular use case. It’s also possible that the ES6 version is fast enough for your use case and is not worth additional time spent refactoring to a more complicated but faster implementation.


Arrow Function

Arrow functions invocation has little performance impact under transpilers. Their native implementation under Firefox is 40-70x slower for calls than the equivalent ES5 operation. Internet Explorer’s performance is approximately that of ES5.

Arrow function declaration on the other hand is slightly slower than the most optimized ES5 implementation, under most environments. Here too Firefox’s implementation shows a large performance hit and IE shows a slight performance hit.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
arrow tests babel 1.3x slower Identical Identical Identical Identical Identical Identical Identical Identical 1.2x faster Identical
traceur 1.3x slower Identical Identical Identical Identical Identical Identical Identical Identical 1.3x faster Identical
es5-bind 10x slower 15x slower 19x slower 14x slower 20x slower 6x slower 6x slower 7x slower 4x slower 2.6x slower 3x slower
es6 38x slower 41x slower 52x slower Identical
arrow-args tests babel Identical Identical Identical Identical Identical Identical Identical Identical Identical 1.2x faster Identical
traceur Identical Identical Identical Identical Identical Identical Identical Identical Identical 1.2x faster Identical
es6 2.9x slower 64x slower 89x slower 68x slower 1.3x faster
arrow-declare tests babel 1.3x slower 1.3x slower Identical Identical Identical 8x slower 10x slower 13x slower 2.3x slower 1.6x slower 1.4x slower
traceur 1.3x slower 1.3x slower Identical Identical Identical 5x slower 7x slower 8x slower 2.3x slower 1.4x slower 1.4x slower
es6 Identical 53x slower 78x slower 78x slower 1.3x slower



With classes we start to see some differences in behaviors. Traceur and the V8 native implementation operate at partity with the ES5 tests when looking at instantiation. Babel’s implementation does suffer a 1.5-60x performance hit for the operations tested. When compiling using Babel’s loose mode, the hit is lessened to 8x.

The super keyword has some fairly large performance issues under all implementations, with the best case being 3x slower and the worst case being 60x slower than the respective baselines. V8’s native implementation also sees a 15-20x performance hit.

Babel’s loose implementation of super is akin to that of the ES5 implementation, utilizing C.prototype.bar.call(this) rather than the slower getPrototypeOf lookup operation that while more accurate technically, incurs an additional cost. This is controlled by the es6.classes parameter but Babel’s authors cite a number of warnings with this flag that may impact compatibility when migrating code to native implementations.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
classes tests babel 2.3x slower 1.5x slower 1.3x slower 1.4x slower 1.3x slower 27x slower 26x slower 30x slower 1.4x slower 1.5x slower Identical
babel-loose 2.3x slower 1.5x slower 1.3x slower 1.4x slower 1.3x slower 6x slower 6x slower 8x slower 1.3x slower 2.4x slower Identical
traceur Identical Identical Identical Identical Identical 1.5x slower 1.7x slower 1.8x slower Identical Identical Identical
es6 Identical Identical Identical Identical
super tests babel 24x slower 60x slower 52x slower 48x slower 45x slower 60x slower 62x slower 61x slower 24x slower 24x slower 16x slower
babel-loose 2.0x slower 1.7x slower 1.7x slower 1.7x slower 1.7x slower 5x slower 5x slower 5x slower 3x slower 3.0x slower 1.2x slower
traceur 12x slower 26x slower 18x slower 18x slower 18x slower 26x slower 30x slower 27x slower 10x slower 12x slower 11x slower
es6 14x slower 19x slower 21x slower 18x slower


Enhanced Object Literals

Object literal extensions generally provide an overhead of up to 147x the baseline. Under the transpiler implementations this is due to the use of defineProperty rather than the much more optimized field assignment. This is done to bullet proof code from potential edge cases discussed here. Loose mode is effectively the same as the ES5 implementation as of 5.6.7

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
object-literal-ext tests babel 4x slower 60x slower 72x slower 71x slower 80x slower 1.8x slower 1.6x slower 1.6x slower 2.6x slower 2.0x slower 2.5x slower
babel-loose Identical 12x slower Identical Identical Identical Identical Identical Identical Identical Identical Identical
traceur 8x slower 120x slower 143x slower 122x slower 144x slower 3x slower 3x slower 2.9x slower 5x slower 4x slower 4x slower
es6 25x slower 23x slower 26x slower 1.4x slower 1.5x slower 1.3x slower Identical


Template Strings

Template strings are a mixed bag. In the basic form, transpilers are able to hit parity with the baseline implementation under most environments. The native implementations are hit or miss. Under Chrome they execute at half the speed and under Firefox up to 650x slower.

Tagged template strings unfortunately do not have such a nice outlook. Their performance ranged from 2x slower for IE’s native implementation to 2000x slower for Babel’s implementation under Firefox. Babel’s loose implementation (es6.templateLiterals) lessens much of the overhead of this operation, at the cost of not having a fully compliant String.raw implementation.


node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
template_string tests babel Identical Identical Identical Identical Identical Identical Identical Identical 1.5x faster 1.4x faster Identical
traceur Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical
es6 Identical 2.0x slower 2.0x slower 1.9x slower 627x slower 622x slower 591x slower 1.3x faster
template_string_tag tests babel 567x slower 578x slower 722x slower 755x slower 820x slower 2395x slower 2349x slower 2028x slower 90x slower 82x slower 61x slower
babel-loose 2.0x slower 1.6x slower 1.7x slower 1.6x slower 1.8x slower 94x slower 87x slower 84x slower 1.4x slower 1.4x slower 2.0x slower
traceur 7x slower 13x slower 17x slower 13x slower 16x slower 346x slower 307x slower 261x slower 13x slower 11x slower 8x slower
es6 8x slower 9x slower 13x slower 9x slower 68x slower 64x slower 59x slower Identical


For destructuring, the average use case effectively matches that of the ES5 counterpart. Unfortunately complex use cases, particularly those around array destructuring, often have large performance overhead. Under Babel an unoptimized helper is used to access the data and under Traceur an entire iterator structure is created, both of which provide fairly substantial memory and CPU overhead over the simple array accessor logic that hand coded ES5 can utilize. Loose mode is effectively the same as the ES5 implementation.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
destructuring tests babel 1.8x slower 1.4x slower 1.4x slower 1.2x slower 1.3x slower 24x slower 22x slower 26x slower 3x slower 5x slower 2.2x slower
babel-loose 1.2x faster Identical Identical 1.2x faster Identical Identical Identical Identical Identical Identical Identical
traceur 26x slower 13x slower 12x slower 10x slower 11x slower 163x slower 152x slower 176x slower 57x slower 25x slower 8x slower
es6 170x slower 148x slower 185x slower Identical
destructuring-simple tests babel Identical Identical Identical Identical Identical Identical Identical Identical 10x slower 1.2x slower Identical
traceur Identical Identical Identical Identical Identical Identical Identical Identical Identical 1.3x slower Identical
es6 Identical Identical Identical Identical


Default Parameters

Default parameters were universally slower for all transpiler implementations. They effectively compile to the same thing, utilizing the arguments object to set a local variable vs. using a named paramemter. This appears to be unoptimzed under all engines and consequently performance was 4-2000x slower. Sadly, this is required in order to properly implement the fn.length behavior defined by the spec:

NOTE The ExpectedArgumentCount of a FormalParameterList is the number of FormalParameters to the left of either the rest parameter or the first FormalParameter with an Initializer. A FormalParameter without an initializer is allowed after the first parameter with an initializer but such parameters are considered to be optional with undefined as their default value.

These scaled numbers should be taken in context. The ES5 equivalents are highly optimized, Firefox pushing over 833 million operations a second in one test, so the net performance of the transpiled versions may very well be sufficient for most use cases, particularly those not on the hot path.

The only native implementation, Firefox, performed identically to the ES5 implementation.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
classes tests babel 2.3x slower 1.5x slower 1.3x slower 1.4x slower 1.3x slower 27x slower 26x slower 30x slower 1.4x slower 1.5x slower Identical
babel-loose 2.3x slower 1.5x slower 1.3x slower 1.4x slower 1.3x slower 6x slower 6x slower 8x slower 1.3x slower 2.4x slower Identical
traceur Identical Identical Identical Identical Identical 1.5x slower 1.7x slower 1.8x slower Identical Identical Identical
es6 Identical Identical Identical Identical
defaults tests babel 17x slower 11x slower 11x slower 9x slower 8x slower 1842x slower 2051x slower 2043x slower 229x slower 72x slower 4x slower
traceur 16x slower 12x slower 12x slower 10x slower 9x slower 1759x slower 2305x slower 1974x slower 210x slower 73x slower 4x slower
es6 Identical Identical Identical

Rest Parameters

Rest parameters are as fast or faster than the ES5 equivalent under almost all implementations. Native implementations provided a performance boost up to 40x (with the exception of V8 where it causes a known deoptimization). Use them with a transpiler. They’re great. Death to arguments.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
rest tests babel Identical Identical Identical Identical Identical Identical Identical Identical 2.0x slower 1.5x slower Identical
traceur Identical 1.5x faster 1.2x faster 1.2x faster 1.2x faster 31x faster 34x faster 27x faster 2.4x slower 1.6x slower 1.3x faster
es6 3x slower 40x faster 42x faster 32x faster 8x faster

Spread Parameters

Under Babel, spread parameters for arrays perform identically to the ES5 counterpart as they are effectively both an apply call. Under Traceur and all of the native implementations the implementations are 1.3x to 17x slower.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
spread tests babel Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical
traceur 13x slower 6x slower 5x slower 6x slower 6x slower 2.7x slower 3x slower 3x slower 9x slower 712x slower 17x slower
es6 3x slower 4x slower 4x slower 1.3x slower 2.5x slower
spread-generator tests babel 150x slower 55x slower 58x slower 66x slower 71x slower 153x slower 143x slower 157x slower 656x slower 423x slower 64x slower
babel-loose 114x slower 46x slower 41x slower 45x slower 53x slower 60x slower 60x slower 61x slower 28x slower 51x slower 22x slower
traceur 27x slower 10x slower 9x slower 10x slower 13x slower 11x slower 10x slower 11x slower 15x slower 1551x slower 9x slower
es6 7x slower 8x slower 7x slower
spread-literal tests babel Identical Identical Identical Identical Identical 1.2x slower Identical 1.2x slower 3x slower 1.7x slower 2.0x slower
traceur 6x slower 3.0x slower 2.1x slower 2.5x slower 2.3x slower 6x slower 5x slower 5x slower 26x slower 451x slower 9x slower
es6 8x slower 7x slower 8x slower 1.8x slower 3x slower

Let + Const

let and const bindings were pretty much identical across the board. While these don’t offer performance improvements (yet), they shouldn’t negatively impact performance.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
bindings tests babel Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical Identical
traceur Identical Identical Identical Identical Identical Identical Identical Identical Identical 1.3x faster Identical
es6 Identical Identical Identical Identical Identical 2.3x slower Identical Identical 1.3x slower Identical


for..of is universally slower, ranging from 3 to 20x slower for array iteration over classical array iteration. When iterating over an object with a custom iterator, the performance is also much slower than for..in iteration with hasOwnProperty checks.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
for-of-array tests babel 21x slower 8x slower 8x slower 9x slower 9x slower 14x slower 20x slower 19x slower 15x slower 489x slower 7x slower
babel-loose Identical Identical Identical Identical Identical 1.4x slower 1.7x slower 1.7x slower 1.3x slower Identical 1.8x slower
traceur 12x slower 7x slower 7x slower 8x slower 8x slower 26x slower 31x slower 32x slower 9x slower 6x slower 6x slower
es6 6x slower 6x slower 8x slower 8x slower 5x slower 7x slower 7x slower 2.9x slower 4x slower
for-of-object tests babel 10x slower 7x slower 8x slower 9x slower 6x slower 6x slower 6x slower 5x slower 60x slower 11x slower 6x slower
babel-loose 10x slower 6x slower 7x slower 9x slower 7x slower 4x slower 4x slower 4x slower 6x slower 449x slower 6x slower
traceur 8x slower 7x slower 8x slower 9x slower 7x slower 9x slower 10x slower 9x slower 5x slower 4x slower 4x slower
es6 6x slower 7x slower 8x slower 6x slower 3x slower 3x slower 3x slower 3x slower


Much like for..of, generators are also quite a bit slower than a raw ES5 implementation of the iterable protocol, with performance ranging from 10x to 750x slower. There is hope here as the V8 implementation achieves parity with the ES5 implementation.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
generator tests babel 601x slower 65x slower 67x slower 63x slower 69x slower 754x slower 723x slower 716x slower 79x slower 499x slower 78x slower
traceur 77x slower 10x slower 10x slower 10x slower 12x slower 48x slower 50x slower 46x slower 18x slower 112x slower 10x slower
es6 Identical 1.2x slower Identical Identical 22x slower 20x slower 19x slower


Maps and Sets

Map and Set all have insert performance that is about 10x slower for a moderately sized data set. All of the implementations show massive improvement on the lookup operations, with Firefox’s native implementation showing a 200x speed increase for a dataset of size 500.

Traceur appears to delegate to the native implementation via their polyfill where possible so performance is closely linked to improvements in the native layer. In runtime mode, Babel does not appear to delegate and performance suffers as a result. Babel’s polyfill mode should behave as Traceur does but this was not directly tested.

Take caution with these numbers. The tests use a data set of size 500 and other data sets will have varying performance but it appears that these features are ready for general use if you have many reads and few writes or need to have objects as keys.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
map-set tests babel 13x slower 3.0x slower 5x slower 5x slower 3.0x slower 105x slower 12x slower 15x slower 60x slower 19x slower 79x slower
traceur 5x slower Identical 2.2x slower 2.3x slower 1.6x slower 20x slower 2.5x slower 2.4x slower 28x slower 2.2x slower 16x slower
es6 5x slower Identical 2.2x slower 2.3x slower 1.6x slower 21x slower 2.2x slower 2.7x slower 28x slower 2.2x slower 15x slower


Promises are across the board faster with both the polyfill and native implementations. This particular benchmark is dubious as it’s both async and inheriently tied to long running behaviors where execution overhead has little impact.

node chrome firefox internet explorer safari
0.10.39 2.3.0 43 44 45 38 39 40 11 12 8
promises tests babel Identical Identical 6x faster 7x faster 7x faster 21x faster 17x faster 16x faster Identical 1.2x slower 3x faster
traceur Identical Identical 2.0x faster 2.0x faster 1.9x faster 36x faster 31x faster Identical Identical 1.8x slower 3x faster
es6 Identical 2.0x faster 2.0x faster 1.9x faster 37x faster 29x faster Identical 1.9x slower 3x faster

Testing methodology

For each of the ES6 features in question, a ES5 implementation of that functionality was written along with a ES6 version. It should be noted that the functionality is frequently the same, but in some cases the “common” vs. “correct” version was written, i.e. using x[key] = value vs. defineProperty which is faster but can be hit but a particular nasty edge case for those who deem it fun to extend Object.prototype.

Babel, in both loose+runtime and runtime mode, and Traceur were then used to compile the ES6 version to a ES5 compliant version, utilizing the runtime over polyfill to maintain test isolation and avoid native implementations where possible.

All of these test instances were then benchmarked in the given JavaScript engine using Benchmark.js and then the operations per second compared to the ES5 implementation. Cross browser and cross execution comparisions are avoided as much as possible to isolate environmental issues when executing on VMs in the cloud.

All of this data, including any updates from more recent test runs is available at http://kpdecker.github.io/six-speed/ and the test suite is available at https://github.com/kpdecker/six-speed for review/feedback.


As noted above, these results might not be representative of your own application since they only test very small subsets of inputs and behaviors of these new features. If you are finding that you have performance issues with your code using these features, you should test them within your own environment to see what the actual behavior is.

While some of these features are a bit slow as of this writing, their performance should only improve as the native implementations mature and are optimized as real world use is applied to them. For the transpilers, there are some performance optimzations that can be made but much of the overhead they are experiencing is due to spec compliance, which they go to great lengths to achieve, but this comes with unfortunate overhead under ES5 implementations as they stand. Babel’s loose mode does offer a bit of a performance boost, but care must be taken when using loose mode as this could cause breakages when code is migrated to the standard native implementations.

Personally I intend to start using most of these features where they make sense but will avoid designing core APIs around these features (perhaps with the exception of Promises) until the native implementations have matured a bit.

4 Comments :, , more...

May Conference Recap

by on Jun.03, 2013, under Web Dev

I had the pleasure of attending portions of Google IO, CSS Conf, and JS Conf and wanted to summarize my notes on these conferences. These are my own take aways and may not have been what the presenter intended. If I’m completely off base, please feel free to drop me a line. This is also not inclusive as there are only so many sessions that one can attend :)

Major Trends


Biggest theme of all of these conferences was attempting to create ways of compoentizing our code so that we can leave the smell of the poo all in one place, to paraphrase @danwrong.


Google has the Polymer framework which polyfils web components. The premise is that you can create truly isolated components that are drop in and do not have worries such as CSS impact from other components.

<element name="my-element">
    I'm a my-element!
  <footer>nothing to see here</footer>
    // When <element> is in document, might run in wrong context.
    // Only do work when this == <element>.
    if (this !== window) {
      var section = this.querySelector('section');
        prototype: {
          readyCallback: function() {
            this.innerHTML = section.innerHTML;

This looks pretty amazing and I think will provide some awesome separation of concerns between content and behaviors in the future. Polyfilling this behavior seems outright genius but at the same time scares me as you are basing a lot of your implementation on something that is being hacked into the browser.

I’m of the opinion that this is amazing future looking work but is a bit more risk than I’d like to take on for my user base.

With standards support for this moving forward I think this is where we will be in 5-10 years depending on the user base that a project is required to support. I also believe that there is a huge opportunity here for developer tooling as this changes some things up that will require changes and improvements to our existing hint/test/minimize/etc tool stacks.


Facebook is doing similar work with their React framework. They have created a new compiled to JavaScript language that allows one to embed html into the source file:

var HelloMessage = React.createClass({
  render: function() {
    return <div>{'Hello ' + this.props.name}</div>;

The framework will then manage the all of the rendering lifecycle without data binding or blanket re-rendering. This is apparently done by a DOM diffing algorithm that walks the DOM tree and updates only the components that need to be on a property change. The presenting team highlighted that you can provide hints to this implementation to improve performance so I do question how well this scales.

I have not had a chance to play around with this implementation but I am not against the html embedded in a JavaScript file like many people in the blogosphere are/have been. I think both this and polymer tackle separation of concerns in a different manner than the HTML/CSS/JS paradigm that has been beat into web developers for so long. I see them as implementing separation of concerns at a content vs. behavior level which may be better for some workflows.


Flight from Twitter attempts to handle componetization at a much smaller level. They focus on defining interfaces between discrete components. Each of these components can focus on only their implementation.

This is lower-level than the systems above and in many ways can be used to build other framework systems.


Performance was a huge concern at all 3 conferences with many sessions devoted to different aspects of performance improvements. My major take aways are:

  • Don’t follow a coding pattern because something is “faster”. What exactly is faster will change as runtimes optimize for the code that they are seeing. Instead look at what the tools are saying and react accordingly.

  • Don’t prematurely optimize. You are probably wrong. Your code is most likely going to be harder to understand and there is plenty that you can spend time as engineering time is finite.

  • Performance is holistic.

    • JavasScript, layout, rendering, compositing, GC, etc. can all impact performance.
    • Newer architectures are moving behaviors out to other threads but this does not work if you try to implement your own behavior. Custom scrolling is the biggest offender here.
    • Under current Chrome implementations touch handlers can cause scrolling issues as it disables certain scrolling optimizations.
  • Chrome is the leader in debugging tools and ability to investigate performance

    • Chrome dev tools timeline panel
    • about:tracing – Google’s internal performance tool
    • V8 tools – In depth V8 profiling tools
    • Continuous painting mode lets you test performance impact of specific elements or properties
    • Remote debugging API (This powers Chrome for Android debugging and topcoat performance monitor)
  • Higher level console commands are useful

    • console.time
    • console.group
    • These are not always evil and can help programmers with onboarding
  • Topcoat has a turbo mode which attempts to remove layout and style calculation from overhead. All elements have style element and are absolutely positioned. On a personal note this seems a bit overboard for 99% of use cases.

  • High-speed cameras can be used in the name of performance testing! :)

Many V8 specific performance recommendations as well:

  • V8 has an optimized/unoptimized state machine that a particular piece of code may jump between. Can’t tell at compile time if something will be promoted to optimized once hot. When profiling should look for * token next to function names to verify that it’s optimized.

  • Memory allocation pattern between optimized and unoptimized are dramatically different. Optimized will often remove temp variables wereas unoptimized will have to GC temp variables.

  • Can monitor state machine with --js-flags="--trace-deopt --trace-opt-verbose". WARN: Very verbose. Pipe & Grep

Better Tooling

Adobe and Google had strong developer tools showings at these conferences.

Adobe demoed some very cool features for their brackets IDE including:

  • PSDLens – PSD inspector assistant
  • Response – Responsive design editor
  • Theseus – Brackets debugger concept
  • Instabug – Live code inspector with visual unit test executor/generator

Additionally they covered some of the tools involved with their topcoat project:

On the Google front, most of the improvements were in the Chrome Developer Tools including:

  • Flame charts
  • Full remote dev tools on Chrome For Android
  • SASS support, generically via source maps
  • Live editing with mapped update support

JavasScript everywhere

One of the other fun themes was the use of JavaScript in more and more places. This included a hacking day on various bots and AR Drones for those who choose those sessions. This culminated with a Nodebot shooting down a NodeCopter and calls for Node-based Aircraft Carriers.

Random Coolness

  • jankfree.org
  • nodesecurity.io
  • webplatform.org
  • @rem demoing game with RTC and getUserMedia
  • @seb_ly giving an amazing presentation including crowd participation from 5000 miles away and live coding over VNC
  • @necolas – Get over yourself. Tech changes every few years and all of the battles today will likely be moot in a few years.

Outside of the above there we’re a lot of fun and interesting sessions that could be discussed in depth but suffice to say that the JavasScript and Web Development communities are very strong and there is a lot of interesting stuff coming down the pipes.

Comments Off on May Conference Recap :, more...

OSX Frontend Toolchain

by on Jan.30, 2013, under Dev

I’m currently in the middle of inventorying my machine so I can retire the time machine image that has spanned far too many years and far too many machines. Rather than stuffing this in Evernote to be used once I figured I’d post this to the community.

What other frontend tools are missing? Which ones have better alternatives?


  • SublimeText 2

    Common plugins include:

    • Package Control – Allows all other plugins to be installed
    • BracketHighlighter
    • Git
    • Handlebars.tmBundle
    • JsFormat
    • JsHint
    • PrettyJSON
    • Stylus
    • SublimeSaveOnBuild
    • TrailingSpaces

    Useful config options:

      "bold_folder_labels": true,
      "draw_white_space": "all",
      "ensure_newline_at_eof_on_save": true,
      "highlight_line": true,
      "highlight_modified_tabs": true,
      "tab_size": 2,
      "translate_tabs_to_spaces": true


  • Git Command Line

    Your mileage may vary but by far the strongest git client out there.

    Most common git commands

    • git checkout -b $newBranchName
    • git stash
    • git pull --rebase (Warn do not do after a branch merge)

    Ensure that your version of git has completions enabled (this might require manual installation)

    Customizing your bash prompt for git status is also very helpful:

    This script whose origin has been lost will output the current branch and change status in your bash profile.

    function parse_git_branch {
      git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
    function last_two_dirs {
      pwd |rev| awk -F / '{print $1,$2}' | rev | sed s_\ _/_
    c_cyan=`tput setaf 6`
    c_red=`tput setaf 1`
    c_green=`tput setaf 2`
    c_sgr0=`tput sgr0`
    function proml {
      PS1='\h:$(last_two_dirs)\[$(branch_color)\]$(parse_git_branch)\[${c_sgr0}\] \u\$ '
    function branch_color() {
      if git rev-parse --git-dir >/dev/null 2>&1
        git diff --quiet 2>/dev/null >&2
        if [[ $? -eq 0 ]]
        return 0
      echo -ne $color
  • Gitx

    GUI frontend on various commit related git operations. The staging view is very valuable for doing interactive commits and self-code review at commit time.

  • SourceTree

    General git repository viewer. Helpful for viewing stashed changes that may have accumulated on your local tree.

  • git-extras

    A collection of useful tools for doing higher level git commands such as delete-branch. When installing make sure that the command line tab completion tools to no error out as these are very helpful.

Debugging and Optimizing

  • Charles

    HTTP proxy and debugger with easy to use interface.

  • xScope

    Inspect/measure mocks and final rendered pages.

  • Gradient Scanner

    (Shameless plug) Extract CSS gradients from flatted mock images.

  • ImageAlpha/ImageOptim

    Image optimization tools. Performs both lossless and lossy compression of image assets.


  • Dropbox

    Easy way to backup remotely and share content across the team.

  • Evernote

    Free notetaking service.

  • MS Office

    Because somethings you can’t escape.

  • MS Remote Desktop Client

    Again somethings you can not escape.


  • Adium

    Chat over many protocols. Most common among the team are GTalk and AIM.

  • Propane

    Team chat. Setup growl notifications and stay connected.

  • Skype

    Sometimes you need to use your voice. Horrible at IM.

  • ScreenFlow

    Generate screen casts for sharing content with coworkers or debugging transient behaviors.


  • Alfred

    Search-based system launcher.

  • Growl

    Common notification system for Lumbar builds and Propane and others.

  • Divvy

    Window position manager

  • Stay

    Utility which will restore your windows when you connect or disconnect a monitor.

  • BetterTouchTool

    Keyboard/mouse/touchpad gesture mapper.

  • Cloud App

    Dirt simple screenshot sharing app. Useful for sharing screenshots and other local content over IM and email when attachments might not be supported or supported easily.

  • Homebrew

    OSS package manager.

  • nvm

    Node version switcher. Easily allows for switching between different versions of node.

    Current recommendations for the latest 0.8 node branch for running the development build stack as the watch issues on the 0.8 branch seem to have been resolved.

3 Comments :, , , more...

Quick: Firediff and Firefocus updated for 5.0 support

by on Jul.06, 2011, under Firediff, Firefocus

Both Firediff and Firefocus have been updated to increase the target application support up to Firefox 5.0.

Both of these are available from the update stream on this site. New installations are recommended to use the Firediff and Firefocus projects on AMO as these will be more responsive to the march of Firefox releases.

Comments Off on Quick: Firediff and Firefocus updated for 5.0 support :, , , , more...

Firediff 1.1.2

by on Mar.21, 2011, under Firediff, Firefox, Web Dev

Just in time for the impending Firefox 4.0 release, Firediff has been updated to version 1.1.2. This release contains compatibility changes for Firefox 4.0 and Firebug 1.7 as well as the ability to sort CSS properties alphabetically.

As always, the latest version is available here and is currently under review at AMO.

2 Comments :, , more...

Firebug Extension Updates: Firebug 1.6

by on Dec.03, 2010, under Firediff, Firefocus

As many of you are already aware, the recent release of Firebug 1.6 introduced some API changes that caused breakages within Firediff. To fix these some minor code changes within Firediff were necessary, thus the 1.1 release that has just been published.

Along with the updates for the new APIs, this version also includes:

  • Copy support
  • Bug fixes for Firebug detached mode
  • Change monitor context menu fixes
  • Slight adjustment to the colors used within the text diffs

There are a few support changes in this release. Rather than trying to support multiple versions of both Firebug and Gecko, official testing is limited to a single version of Firebug, 1.6, and as a consequence for Firebug 1.6 to a single version of Firefox, 3.6. This is simply due to the increased QA time that is required to test all of the permutations of Firebug version, Gecko version, and OS type. When updating for the changed APIs in Firebug 1.6 attempts were made to maintain compatibility with Firebug 1.5, but this configuration is no longer officially tested.

Since I was going to through the release process for Firediff I decided to release the 1.2 version of Firefocus as well. This version implements the uk-UA locale but is otherwise the same as 1.1.

Firediff 1.1 is available here on incaseofstairs and is currently under review on AMO. Firefocus 1.2 is available here on incaseofstairs and is currently under review on AMO.

Thanks to everyone who notified me of the breakage when 1.6 was released. It’s great to hear feedback from users and to hear that the project is in active use! As always please do not hesitate to let me know how the project is working for you, good or bad.

6 Comments :, , , more...

Cross Platform Text-Indexer

by on Nov.25, 2010, under Web Dev, webOS

While working on a recent Facebook release we ran into a performance bottleneck within the Mojo.Format.runTextIndexer API. Performance on device was on the order of a couple of seconds to process the content for feed items 30-50. This combined with the other tasks in the formatting and rendering cycle led to poor performance in the news stream.

For those who are not familiar with the Mojo.Format.runTextIndexer API, this API scans human generated text for URLs, phone numbers and email addresses, replacing the plain text representation with HTML links to the particular object. Additionally this API will replace emoticons with image representations on supporting platforms.

With the news stream scene being the primary scene in the application it was vital that we make this as performant as possible so I spent some time profiling this and determined that the bulk of the time in this operation was spent in the generic C indexer logic. Since at it’s core this is just a text scanning heuristic that, for the most part, does not rely on any C-level constructs, I decided to investigate a Javascript implementation to see if this would be more performant.

The result was a Javascript implementation that was many magnitudes faster than the core implementation (multiple seconds vs. ~10ms for a variety of Facebook news feeds), allowing for much faster execution as well as the creation of the library being released today.

While this library is designed primarily for webOS applications, it has also been designed to work in cross-platform environments for all functionality other than the emoticon replacement which requires platform specific logic to determine the proper image to replace.


There are two key components to this implementation, the cross platform link indexer and the platform specific emoticon processor.

The link indexer is a two-stage regular expression, using the quite daunting INDEXER_REGEX regex to extract possible linker tokens with Javascript being used to determine the meaning of each token (or throwing it out just text content).

The emoticon processor is implemented by scanning for known, or possibly known, emoticons using the EMOTICON_REGEX regex and then passing these tokens to the platform’s text indexer implementation. Doing this allows for our own custom implementation while retaining the look and feel of emoticons used by the rest of the platform. For non-Mojo platforms this logic is disabled and emoticons will be left unmodified, with minimal change.


HTML Content

Like the API this aims to replace, this API does not handle HTML context when replacing content. As a consequence this algorithm can break HTML content. In order to prevent this, the input and outputs for the TextIndxer.run API should be considered text or minimal HTML that will not match any of the replacements.

It is still possible to use this with content containing HTML by processing in a manner similar to the following although the input still needs to be filtered for XSS and other security concerns.

        var srcText = $(this).val(),
            womb = $("<div>" + srcText + "</div>");

            .filter(function() {
                return this.nodeType === Node.TEXT_NODE;
            .each(function() {
                var text = $(this),
                    indexedText = TextIndexer.run(text.text()),
                    womb = $("<div>" + indexedText + "</div>");
                womb.contents().each(function() {



Framework Override

By default this library overrides the Mojo.Format.runTextIndexer API (when used within the Mojo framework). Care should be taken with each OS upgrade to ensure that this override does not break any expected behavior. If uncomfortable with this override then it can be removed by removing these lines from the library and using the TextIndexer.run API directly.

    // Mojo Framework override. Unused on non-Mojo platforms and may be removed if undesired in Mojo apps
    if (window.Mojo && Mojo.Format) {
        // Override the Mojo API if it exists in this context.
        Mojo.Format.runTextIndexer = TextIndexer.run;


The code is available on Github within the text-indexer repository. A cross-platform live demo is also available here.

3 Comments :, , , more...


by on Aug.01, 2010, under Web Dev

Recently heard about the relatively new jsPerf service that Mathias Bynens has created and after spending some time playing around with this on my own machine I can honestly say that I love this service. Rather than a few gushing tweets on the subject, I felt like this deserves a blog entry covering it’s coolness.

The thing that I found the most striking about the site (and most likely the reason that I am writing this now) is that it broke many of my previous assumptions about performance of specific statements and relative performance of different platforms. Is innerHTML faster than DOM manipulation when generating a DOM tree? Not for a specific (relatively simple) construct under Chrome (OS X v5). Is array.join(”) the fastest way to concat a string. On my test platforms (OS X Firefox, Safari, Opera, Chrome release versions), nope.

Being a public playground, the community benefits from the collective knowledge. Scanning through the test list I saw many of the problems that I have run into before as well as some I had never considered such as the multiple methods of performing a Math.floor operation. While some of these honestly scare me and remind me of Kernel code, it’s good to know they exist.

jsPerf has full support for mobile browsers as well, meaning that you can test performance test the various algorithm options on device and have a realistic view of how it will behave on the device. In running some of the tests on a webOS device there were some quite distinct differences between comparable environments on a desktop class machine.

As with any performance testing I would recommend running these tests multiple times on your target device(s) before selecting a particular path to use as there are many things that could cause a single test to provide inaccurate results for a given execution, particularly on the more resource constrained environments.

Great job Mathias and can’t wait to see what features are added to this as well as the content that the community creates!

1 Comment :, more...

Implementation: Facebook for webOS Add Tag UI

by on Jun.04, 2010, under webOS

Add Tag Interface

Facebook Add Tag Interface

Yesterday we released Facebook for webOS 1.2.5 Beta which brings many improvements to our photo functionality including tagging support. Now that the release is out the door, I’d like to take some time to discuss the cooler aspects of the implementation particularly the Add Tag UI.


The core layout of the Add Tag UI is an overlay container containing a fixed position header and a scrolling list below that. The entire screen is covered by these two elements, with the header section maintain its height and the content section expanding to cover the remainder.

This fixed header layout is fairly common throughout the app, the most common example being the navbar used in the majority of the application’s scenes, and is fairly easy to solve if the header is a fixed height and the content scrolls under the header. All that needs to be done is to position the header control using position: fixed and apply a margin-top to the list such that the first element in the list appears at the bottom of the fixed element.

I’ve never really like this solution as it requires that the header height be fixed and the list section be “aware” of the header rather than being only concerned about it’s own layout. With this in mind (and also wanting to play around with some of the cool things that WebKit offers but I have not been able to use on projects due to the IE factor), I decided to try out the flexible box layout type in webOS.

Flexible Box Layout

To provide some background, one of the key goals of the flexible box layout module is the ability to specify the size and growth of an element relative to both it’s siblings and it’s parent. While this was previously possible by using percentage layouts, each of the elements had to be aware of the size that their siblings expected and all elements needed to use the same relative system.

This is not the case with this layout scheme. Rather than defining a percentage of the container size, elements are defined with an affinity for the excess space in the container. This means that the layout first attempts to fit everything as it would normally layout, then adjusts each element based on the difference in size between the children and the parent. In practice this can generate much more stable, but still fluid layouts when creating applications in HTML+CSS.

The box-flex (-moz-box-flex, -webkit-box-flex) is used to define the resize affinity.

Values here can range from zero to any positive decimal value. When the value is zero, the element will not change size based on extra or lack of space in its parent. When this value is larger than zero the element is considered flexible. This means that when the layout engine determines that the parent box is either overflowed or underflowed these elements will expand or shrink such that all of the children fill the container. The differences in magnitudes of this value determines how the flexible elements are resized.

As an example a vertically oriented flexible box with 3 children whose flex values are 0, 1, and 2 and has 60px of open space will add 20px to the second element, 40px to the third element and leave the height of the first unchanged. On the other end of the spectrum if there is an overflow of 60px, the elements will be shrunk by the same dimensions above.

The flexible box model is supported by Safari 3+, Chrome 3+, Firefox 3+, and of course webOS. As covering the entirety of the specification was out of the scope of this post I would recommend reading some of the other excellent sources on this topic as well as the specification itself.


For the Add Tag UI, we take advantage of the flexible overflow case outlined above. This allows the upper section to layout at it’s natural size using -webkit-box-flex: 0 and the user list section to expand to fill the remainder of the page using -webkit-box-flex: 1. By defining the list section to be a Scroller with an embedded List, we can maintain fixed behavior for the upper section and still allow for an arbitrary number of users.

Implemented this looks something like the following:

<div class="tag-selector">
  <div class="tag-selector-panel">
    <div x-mojo-element="TextField"></div>
    <div class="form-wrapper">
      <div x-mojo-element="Button"></div>
      <div x-mojo-element="Button"></div>
  <div class="tag-scroller" x-mojo-element="Scroller">
    <div x-mojo-element="List"></div>

With the CSS doing most of the heavy lifting:

.tag-selector {
  position: absolute;
  top: 0;
  left: 0;
  bottom: 0;
  right: 0;

  z-index: 1000;

  display: -webkit-box;
  -webkit-box-orient: vertical;

.tag-scroller {
  position: static !important;
  -webkit-box-flex: 1; 

A live demo for Firefox and Safari/Chrome available is available here. Note that the demo is running a modified version to handle desktop and cross-browser differences. These are mostly experimental prefix concerns i.e. display: -webkit-box becomes

    display: -webkit-box;
    display: -moz-box;
    display: box;

Although there are a few hacks in place to force common layout under both WebKit and Gecko (See Bug 570036). Such is life developing with CSS3 :)

Future Posts

As a final note, I’d like to start a series of these posts. Are there any sections of the Facebook app that you would like me to provide an overview of their implementation? Feel free to comment on this post or drop me a line at kpdecker@gmail.com.

2 Comments :, , , , more...

border-image-generator: Local File Access

by on May.31, 2010, under border-image-generator, Web Dev

This article covers the techniques used to implement the local file access feature that is included, along with tiling support, alternate styling, and parameter optimization, in the most recent push to border-image-generator.

One of the biggest short comings that I felt like border-image-generator was that all files had to be posted on a HTTP server due to restrictions on the access to the file:// protocol. In my personal workflow this was somewhat of a pain, so I set out to find a way around this issue.

During the design of this feature, I quickly decided that all data must remain on the client as I did not want to upgrade my hosting service to include more bandwidth, felt like responsiveness could be a concern, and do not want to tangle with the potentially messy privacy issues that could arrise from storing user generated images on my server.

While this sounded like a daunting task, it turns out that this was possible, in sufficiently advanced browsers, using a variety of HTML5 techniques, including Data URIs, the File API and the Web Storage API.


The problem of displaying the image was the easiest to solve as all of the targeted browsers support data URIs as part of the border-image property. This allowed the application to generate URLs like the following

    border-width: 46px;
    border-image: url("data:image/png;base64,iVBORw0KGgoAAA....") 46 stretch;

And operate as expected. Data URIs have been covered fairly extensively elsewhere, so I will leave this to the reader to investigate.


With the actual display issue solvled, there was still the non-trivial issue of actually loading the content. My initial investigations involved Flash, which provides FileReference.load API which allowing for this functionality, but under the version I was testing on this API is only usable if invoked in response to user input. Being a HTML guy and lacking functional knowledge of the Flash development process I quickly ruled this technique out.

Continuing my research I came across an article on MDC that covered this exact use case, using the draft File API specification. This worked like a charm, even exposing the ability to read the image contents directly into a data URI.

The API is very clean for use cases such as this:
function loadFile(file) {
    var reader = new FileReader();
    reader.onload = function(event) {
         updateImageURI(file.name, reader.result);

Where the file variable above is a File object retrieved from a

<input type="file">
or the dataTransfer object passed to the drop html event.

        $("body").bind("dragenter dragover", function(event) {
            // We have to cancel these events or we will not recieve the drop event
        $("body").bind("drop", function(event) {
            var dataTransfer = event.originalEvent.dataTransfer,
                file = dataTransfer.files[0];

        $("#localImage").bind("change", function(event) {
            var file = this.files[0];


This unfortunately is not without it’s issues. The File API is very much bleeding edge at this point and support is somewhat limited. As of this writing Firefox is the only browser which features this in production (Version 3.6). Support landed in the WebKit trunk literally earlier this month and can be used in their nightlies, but so far has not made it into any production releases.

The site is currently designed to progressively enhance as it detects support for the File API, so no need to worry about being left out of the site as a whole if you are not on one of these browsers yet.


After loading the content using the File API, the original implementation utilized the same #hash storage method for the data URIs, but this proved to be problematic as these strings can become quite large and interacting with these URLs was unwieldily. Needing another data store and being forced to maintain a cache of all local images due to the security model employed by the File API, we were left the options of storing all data in Javascript space or using the new Web Storage APIs implemented as part of HTML5.

Examining both options it seemed the the best course was to utilize the sessionStorage object when available and fail over to the javascript data model when not.

    // Check for browser support of session storage and that it is accessible
    // This may be inaccessible under certain contexts such as file://
    function supportsSessionStorage() {
        try {
            return !!window.sessionStorage;
        } catch (err) {
            return false;
    var localDataBinding = (function() {
        if (supportsSessionStorage()) {
            // If they support FileReader they really should support storage... but who knows (With the exception of file://)
            return {
                storeImage: function(name, data) {
                    var entryId = (parseInt(sessionStorage["imageList-count"])||0)+1;
                    sessionStorage["imageList-count"] = entryId;
                    sessionStorage["imageList-src-" + entryId] = data;
                    sessionStorage["imageList-display-" + entryId] = name;
                    return entryId;
                getImage: function(entryId) {
                    return { src: sessionStorage["imageList-src-" + entryId], displayName: sessionStorage["imageList-display-" + entryId] };
        } else {
            // Fail over to plain js structures, meaing that refresh, etc will cause failures.
            var cache = [];
            return {
                storeImage: function(name, data) {
                    cache.push({ src: data, displayName: name });
                    return cache.length-1;
                getImage: function(entryId) {
                    return cache[entryId];

Working with this API it seems as though it is still somewhat rough. The vendor documentation all state that supported datatypes are only string values (Mozilla, WebKit), but the spec implies that this will change be final release and allow for storage of a much broader set of datatypes.

A consequence of this design is that boomark and URL sharing for local files is not a possibility. For users who need to share or store application states the image in question will need to be stored on a HTTP server and accessed by this route.

These changes as well as some incremental changes have been pushed live on border-image.com and are available in the github repository.

1 Comment :, , more...

Visit our friends!

A few highly recommended friends...