[phase_9]

Yet another promises library (: It's great that people are writing and sharing code, but it feels like people are trying to re-invent the wheel when stable, mature and well tested libraries[0] already exist for these problems.

[0] https://github.com/cujojs/when

[wycats]

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]

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]

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]

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.

[aufreak3]

I'm not sure the wheel has really been invented yet, at least in the case of JS. One of the things I found was that all the libraries had little or nothing to say about "error handling". Error handler bodies are always given with a comment like this -

    function (error) {
        // handle error
    }

What do you do there? Exit the process? How to recover and continue from some critical point? Can you retry some part of the action? Can you try some alternative actions if something fails?

So I felt we can do better and .... surprise .... wrote my own heavy weight (1 kloc) library that provides a richer-than-usual set of composeable async primitives emphasizing error management including recovery, restarts, alternatives, etc.

So, here is yet another "wheel" :)

https://github.com/srikumarks/IO.js