When reading through jQuery's decision to stick with their implementation of promises, a mention of performance considerations piqued my curiosity and I decided to do a quick performance test. I used Benchmark.js and tested the results of creating and resolving a deferred object with a success handler in .then().
thanks for describing promise/deferred. What i miss though is an explanation, as to why this is better than simple callbacks/events especially in the javascript world.
In the end, i have to define callbacks in the promise anyway, so why the whole caboodle in the first place?
When reading through jQuery's decision to stick with their implementation of promises, a mention of performance considerations piqued my curiosity and I decided to do a quick performance test. I used Benchmark.js and tested the results of creating and resolving a deferred object with a success handler in .then().
The results:
jQuery 91.6kb When.js 1.04kb Q.js 8.74kb 9,979 ops/sec ±10.22% 96,225 ops/sec ±10.10% 2,385 ops/sec ±3.42% Note: minified with Closure compiler, not gzipped
After running these tests, I discovered a much more in-depth test-suite of promise libraries which reveals similar overall results.