3 ms·

My goal was to have a small, lightweight promises implementation that could be easily embedded in other browser-based libraries. I specifically wanted a very sm

by wycats 14y ago

My goal was to have a small, lightweight promises implementation that could be easily embedded in other browser-based libraries. I specifically wanted a very small API surface area, essentially limited to the surface area described by the Promises/A spec. My requirements matched closely with the promises test-suite recently released, including a requirement that all promises be delivered asynchronously and efficiently if possible (`when` does not satisfy this requirement). I could not find any existing small, embeddable libraries that satisfied all of these requirements.

Cogito 14y ago
Out of interest, what other libraries did you consider? A break down of pros and cons for each would be really useful, and I'm not sure anyone has done that already (at least I can't find any after a quick search).
- wycats 14y ago
  jQuery.Deferred: Too coupled to jQuery, doesn't chain, not async Q: Too monolithic promise-stream: inadequate chaining support and node-specific when.js: synchronous delivery, much larger API surface area than Promises/A For what it's worth, promise-tests was written by Domenic Denicola, a contributor to Q, who seemed happy to have a lightweight entrant that implemented promises correctly.
  - Cogito 14y ago
    Thanks for that, it's a good snapshot of the current state of promises. The readme in the repository has some good discussion around the different features you mention here, but it would be really interesting to see a discussion around the design of this library in counterpoint to the other options available. Some other time maybe! With regards to the promise-tests, I think multiple implementations validate a concept, and a set of tests for a specification is much more useful when multiple implementations can pass it. If the specification is extended you have multiple implementations to compare the impact against, and if the implementations' behaviour differ in notable ways then you expose holes in the test suite. Multiple implementations of a specification, particularly when they all pass a common test suite, is a good thing.

by wycats 14y ago

Cogito 14y ago

Out of interest, what other libraries did you consider? A break down of pros and cons for each would be really useful, and I'm not sure anyone has done that already (at least I can't find any after a quick search).

wycats 14y ago
jQuery.Deferred: Too coupled to jQuery, doesn't chain, not async Q: Too monolithic promise-stream: inadequate chaining support and node-specific when.js: synchronous delivery, much larger API surface area than Promises/A For what it's worth, promise-tests was written by Domenic Denicola, a contributor to Q, who seemed happy to have a lightweight entrant that implemented promises correctly.
- Cogito 14y ago
  Thanks for that, it's a good snapshot of the current state of promises. The readme in the repository has some good discussion around the different features you mention here, but it would be really interesting to see a discussion around the design of this library in counterpoint to the other options available. Some other time maybe! With regards to the promise-tests, I think multiple implementations validate a concept, and a set of tests for a specification is much more useful when multiple implementations can pass it. If the specification is extended you have multiple implementations to compare the impact against, and if the implementations' behaviour differ in notable ways then you expose holes in the test suite. Multiple implementations of a specification, particularly when they all pass a common test suite, is a good thing.