Performance Comparison on Javascript Frameworks - DBMonster App

Tl;dr: Blog Post comparing performance of the dbmonster web app written in React, Ember, Underscore, Ractive and Paperclip.

Background

Runtime performance is one of the key focus areas for most modern javascript frameworks. During a talk at the recent ReactConf 2015, a simple app simulating DB queries was used as a way to compare angular, ember and react. Many independent implementations of the test application have emerged since, each trying to showcase how fast the corresponding framework is.
Instead of comparing performance visually, I wanted to see if I could quantify the results and have a way to reproduce them. Note that there is a metric measuring memory, but rendering smoothness may not correlate directly to this metric.

Test Environment

The test suite compares the smoothness of dbmonster implementations in each of the framework. I ran the scroll/smoothness tests from telemetry using browser-perf to collect metrics like frame rates, layout times, nodes impacted per layout, etc.
Since some of the implementations in the original repo seemed slow, I picked up the fastest implementations for each of the frameworks that I could find. I was able to compare the apps written for react, ember, underscore/backbone, ractive and paperclip.
To run the tests,
  1. Download Chromedriver and start it.
  2. Clone the gist - git clone https://gist.github.com/e1becd4ebf528cbf6bfa.git
  3. Install all dependencies with npm - $ npm install browser-perf
  4. Run $ node index.js to start the test for all urls. 
  5. Results of all runs will be available in data.json. 
Metrics for each framework were averaged over 10 runs. 4 such averages were collected for each framework to remove anomalies and to ensure that the metrics were similar in relation to each other. Note that I have not looked under the hood for each of the implementations.

Test Results

Here are some of the interesting facts from the tests.
  • Frames Per Second (calculated using RequestAnimationFrame) - Paperclip was the smoothest, followed by ractive, underscore/backbone, ember and finally react.
  • Frames Per Second (using about:tracing benchmarking) - This metric is a little different and is much closer to actual screen frames. I was not able to collect the data for ractive or underscore. This metric indicated that though ember did not do well on animation frames, it definitely had better times when drawing on the screen.
  • Average time spent painting on the page was highest for ember. React was much lower and the other three were even lower, with similar numbers.
  • Layouts - React's virtual DOM shines here, making it spend the minimum time in layout operations. Underscore seems to be the max, with ember and others in the middle.
  • Recalculating Styles - Underscore/Backbone spent the maximum time recalculating styles, while React's Virtual DOM clearly showed the reason for the lesser time. 
  • GC Events - Ember spent the maximum time collecting garbage, while paperclip was much better again. 
  • Nodes changed per layout cycle - Ember seems to change the maximum nodes, while React's Virtual DOM seems to show its work again here.
  • React was the only framework that seemed to emit events and parse HTML, the latter possibly due to JSX. The events may be the cause for lower frame rates in react despite it performing better at layouts and paints.
Here is the entire spreadsheet, showing averages from each test set, with interesting rows marked in green.

Next Steps

If you have trouble running these tests and see different results, please do ping me. If you are also aware of faster implementations or would like to try this on your framework, I would be glad to help.
Clearly, developers are not just optimizing to deliver content to the user fastest, but also working to ensure that the content enables a smooth experience. I also read about the glimmer implementation for ember and was hoping to work on a test suite that would measure the improvements in event incremental commit. I was also hoping to work a little more with React and Radium to profile for performance. 

OpenTweet - GopherGala Hackathon project

I participated in the online Gopher Gala hackathon with Jeff last week, and we came up with an interesting project. The idea was to create an open tweeting platform/protocol. As Jeff explains it, this is like email, but it pulls tweets instead of pushing mails. The tweets can reside on any server and a user, identified by [email protected] can be followed by any client, using the standard, simple protocol.
For the fun of it, we made the protocol on top of TCP sockets, instead of JSON over websocket pull, or other alternative mechanisms. Here is a demo that shows a ChromeApp and an iOS Cordova client interacting with a couple of servers that host the tweets.


Any user can host and control their own servers, and can use any mechanism to authenticate to the server and post tweets to it. For the demo, we used a simple RESTful API, but the real power of such a system would be the ability to do things like scheduling tweets, summarizing or aggregating tweets from other followers, etc. You don't even need an account to follow others!
The client is a ChromeApp with the UI using Ionic and Chrome Sockets. Being a Cordova commiter, I also converted it to a Cordova app using mobile-chrome-app that comes packaged with appropriate plugins to fill in for the Chrome API.
The source is on github, and if you like the idea, please vote for us :)