In my previous post in Danish I looked at how to perform asynchronous calls by using promises. Now the time has come to pick which library that fits the next project.
There is a lot of variants and the spread is huge. One search for promise via the node package manager npmjs.org gave 1150 libraries which either provides or are dependent on promises. Of these I have picked 12 different libraries to look at, all are open source and all offer a promise-like structure.
- 2014/03/06 – Fixed a few misspellings (@rauschma via Twitter)
- 2014/03/07 – Removed raw sizes, since they did’nt make much sense (@x-skeww via Reddit)
- 2014/03/07 – Added that catiline uses lie underneath. (@CWMma via Twitter)
- 2014/03/07 – Added clarification on what the test does. (@CWMma via Twitter)
The API across the libraries are almost alike, so I’ve decided to look at:
What kind of generic promise related features does each library offer?
And I’m thinking mostly browsers here – how many extra bytes will this add to my site?
How fast are the basic promise operations in the library? You would expect that these will execute many times so this is important.
First an overview of the selected candidates, their license and author. Note that the name is linking to the source of the library (typical Github).
|Bluebird||MIT||Petka Antonov||Loaded with features and should be one of the fastest around and with special empathizes on error handling via good stack traces. Features can be toggled via custom builds.|
|Catiline||MIT||Calvin Metcalf||Mostly designed for handling of web workers but contains a promise implementation. Uses lie underneath.|
|ES6 Promise polyfill||MIT||Jake Archibald||Borrows code from RSVP, but implemented according to the ECMAScript 6 specification.|
|jQuery||MIT||The jQuery Foundation||Classic library for DOM-manipulation across browsers.|
|kew||Apache 2.0||The Obvious Corporation||I’m guessing it is pronounced ‘Q’, can be considered as a optimized edition of Q but with a smaller feature set.|
|MyDeferred||MIT||RubaXa||Small Gist style implementation|
|MyPromise||MITfirstname.lastname@example.org||Small Gist style implementation|
|Q||MIT||Kris Kowal||Well known implementation, a light edition of it can be found in the popular AngularJS framework from Google.|
|Yui||BSD||Yahoo!||Yahoo’s library for DOM-manipulation across browsers.|
The following is a look at the library feature set, looking only at features directly linked to promises:
|Promises/A+||Progression||Delayed promise||Parallel synchronization||Web Workers||Cancellation||Generators||Wrap jQuery|
|Bluebird||✓||✓ (+389 B)||✓ (+615 B)||✓ (+272 B)||-||✓ (+396 B)||✓ (+276 B)||✓|
|ES6 Promise polyfill||✓||-||-||✓||-||-||-||-|
The numbers in parenthesis by Bluebird is the additional size in bytes each feature will add.
Is the Promises/A+ specification implemented?
Are methods provided for notification on status on asynchronous tasks before the task is completed?
Can you create a promise that is resolved after a specified delay?
Are there methods for synchronization of multiple operations, can we get a resolved promise when a bunch of other promises are resolved?
Can asynchronous code be executed via a web worker – pushed to a separate execution thread?
Can promise execution be stopped before it is finished?
Can promises produced by jQuery be converted to this library’s promises?
Every library have been minified via Googles Closure compiler. All executed on ‘Simple’ to prevent any damaging changes. For libraries that support custom builds I have picked the smallest configuration that still supports promises. The result is including compression in the http-stack, so its actually the raw number of bytes one would expect that the application is added when using each library:
The speed has been measured via the site jsPerf which gives the option to execute the same tests across a lot of different browsers and platforms including mobile and tablets. The test creates a new promise with each library and measures how much latency is imposed on execution of the asynchronous block (see more detailed explanation here). Note that the test was not created by me, but a lot of fantastic people (current version is 91). The numbers are average across platforms:
Over half of the worlds websites already uses jQuery. If you have worked with promises in jQuery, you quickly find that they are inadequate.
I have previously had problems with failing code that doesn’t reject the promise on error as you would expect, but where the error still bubbles up and ends up being a global browser error. The promise specification dictates that errors should be caught and the promise rejected, which is not what happens in jQuery.
So if you today have a site based on jQuery, the obvious choice is to pick one of the libraries that offers conversion from jQuery’s unsafe promises to one of the more safe kind. If size is a priority either Q or when are good suggestions, loaded with features and at a decent speed.
If you are less worried about size, Bluebird is a better choice. The modularity makes it easy to toggle features and it has a significant test suite that covers performance on a lot of other aspects than the single one covered by this post.
If performance is essential, kew is a good bet. A team has picked up Q and looked into lowering its resource requirements. This has resulted in a light weight but very fast library.
If you are looking for a more limited solution with good speed and without big libraries, the ES6 Promise polyfill is a good choice – then in the long term when the browsers catch up, the library can be removed completely.
This post is also available in Danish at QED.dk