

Rsvp.js - dko
https://github.com/tildeio/rsvp.js

======
tlrobinson
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>

~~~
wycats
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.

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

~~~
amix
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 ;-)

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

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

------
itodd
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>

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

~~~
pfraze
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.

------
olalonde
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>

~~~
jergason
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.

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

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

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

~~~
wycats
`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".

~~~
bengillies
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...

