Rsvp.js(github.com)

94 pointsby dko14 anni fa25 comments

https://github.com/tildeio/rsvp.js

8 comments

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

wycats14 anni fa

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.

jherdman14 anni fa

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

amix14 anni fa

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

tbranyen14 anni fa

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

netghost14 anni fa

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

jakejake14 anni fa

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

wycats14 anni fa

It doesn't.

phase_914 anni fa

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

wycats14 anni fa

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.

Cogito14 anni fa

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

wycats14 anni fa

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.

Cogito14 anni fa

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.

aufreak314 anni fa

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

[deleted]14 anni fa

itodd14 anni fa

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

matthuggins14 anni fa

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.

pfraze14 anni fa

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.

lancefisher14 anni fa

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.

olalonde14 anni fa

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

jergason14 anni fa

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.

firefoxman114 anni fa

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

amasad14 anni fa

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

bengillies14 anni fa

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

wycats14 anni fa

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

bengillies14 anni fa

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