Good to see more implementations of Promises/A. It would be really nice if everyone settled on one promise API.

Check out "Q" as well: https://github.com/kriskowal/q

There are adapters for many of Node's APIs (and it's easy to create more)

https://github.com/kriskowal/q-io

https://github.com/kriskowal/q-fs

https://github.com/kriskowal/q-http

The suite I used for this project has a primary suite and a series of extensions that I personally thought was a very good articulation of the currently accepted API, even such as it is.

Currently, only RSVP and Q pass the entire suite.

Does this differ wildly from jQuery's Deferred object? http://api.jquery.com/category/deferred-object/

Deferred pattern isn't from jQuery. It's from Twisted and the first JavaScript library to use it was MochiKit. A nitpick I know, but I think it's good to know where things really come from ;-)

He didn't say it originated from jQuery. The question is solid, because jQuery is probably the most used implementation.

Same basic principle, it's a Promise library, but this one is by wycats.

I'd be curious to know if jQuery Deferred object passes the same promise test that RSVP.js mentions. (Not quite curious enough to run the test myself though, work is a bit to crazy today. Wait, what am I still doing on HN!)

It doesn't.

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

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.

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).

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.

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.

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

I've been using underscore's _.after [0] to help manage my async code. It's extremely simple and does the job.

[0] http://underscorejs.org/#after

This is actually very cool. I've never heard of Promises/A before, but after toying with Node.JS a bit (and being turned off after having many nested callbacks in my code), I am definitely a fan of the flat code structure this library allows.

Although it's obviously not built in favor of any particular JS framework or environment, it may entice me to give Node.JS another shot in the future with implementing RSVP.

I've been using promises for my work lately, and I really like them. This doesn't have it, but one construct I use is the `when` function. It's useful for situations that may return non-promise values, and works like this:

    Promise.when(func(), function(val) {
        alert(val);
    });

So if `func` returns a normal value, the cb runs immediately. If it returns a promise, the cb runs on fulfillment.

Nested callbacks are a problem that every javascript/node.js developer runs in to. A common library to help with this and other issues is Async: https://github.com/caolan/async

Sometimes, it's just better to give your functions names, and pull them out.

RSVP.js looks nice. Also, I like jQuery's implantation of promises specifically with the ajax function.

How is this different from the async library? Are they both trying to solve the same problem or are they complementary? https://github.com/caolan/async

They are both trying to solve the problem of handling asynchronous operations in an easier way than nested callbacks.

Promises are a different abstraction of async operations. I am still trying to wrap my head around them fully, but one of the advantages seems to be writing code that looks a little more sequential.

If anyone wants a simpler async flow control lib in under 20 LOC check out my Valv library: https://github.com/kevinmctigue/valv

Looks great. How is using mutation events for async better than `setTimeout(fn, 0)` ?

Not having tested it personally I can't say, but I'd imagine it's a lot faster.

I'd be more interested in how it compares to using postMessage which, from testing, is definitely a lot faster than setTimeout (like fast enough to be worth switching to if available).

`postMessage` is faster than `setTimeout` but is unreliable. For example, it's synchronous in IE8. I may add support for `postMessage`, but for now I support "new and reliable" and "old and reliable".

Hmm, didn't know that, thanks. I suppose if you really wanted to you could add a test to see if postMessage was async or not...