I will speak mostly to Q, since I am a co-maintainer.
Q has historically stemmed from the work of Mark Miller, one of the authors of the E programming language, from which JavaScript promises are largely inspired. As such, it aligns with his larger goals for a promise ecosystem, which include object-capability security and using promises as proxies for remote objects. For an example of promises applied in these contexts, see his paper at [1].
In practice, all of this is somewhat theoretical, as Q also serves a large constituency of "normal" promise users in Node and the browser. There, it differentiates itself via a focus on features and integrity over speed (mainly as a matter of prioritization; we like speed too!); excellent Node.js integration [2]; and an internal system which allows promises for remote objects via Q-Connection [3] (but also gives some nice methods for promises for objects etc. for the same-machine case [4]).
I would say that Q is my favorite library to work with, as it has thought out its design choices in a depth I don't see in the other libraries---or perhaps more accurately, the choices they have made don't align with my sense of craftsmanship as well :). That said, you should probably not use it if your concern is speed. We have always taken the position that, while speed is nice, most of the time you are doing an asynchronous operation anyway, so any overhead from the promise library will matter very little.
"ref_send", the ability to create a deliverable value, would be my core linkage on Q and more-so promises (as not an author)
http://waterken.sourceforge.net/ .
The background is interesting, but I'm not sure what value an association with historical context brings. I've tried other promise libraries, but stub my toe on missing capabilities I'm used to, or end up distracted with mechanics. I don't think I've ever found myself saying, gee, would that this be closer to ref_send, but then again almost all implementations happen to tack close to. So, uh, Domenic does have a more useful account of Q. Mostly here to drop some ref_send. ;)
Q has historically stemmed from the work of Mark Miller, one of the authors of the E programming language, from which JavaScript promises are largely inspired. As such, it aligns with his larger goals for a promise ecosystem, which include object-capability security and using promises as proxies for remote objects. For an example of promises applied in these contexts, see his paper at [1].
In practice, all of this is somewhat theoretical, as Q also serves a large constituency of "normal" promise users in Node and the browser. There, it differentiates itself via a focus on features and integrity over speed (mainly as a matter of prioritization; we like speed too!); excellent Node.js integration [2]; and an internal system which allows promises for remote objects via Q-Connection [3] (but also gives some nice methods for promises for objects etc. for the same-machine case [4]).
I would say that Q is my favorite library to work with, as it has thought out its design choices in a depth I don't see in the other libraries---or perhaps more accurately, the choices they have made don't align with my sense of craftsmanship as well :). That said, you should probably not use it if your concern is speed. We have always taken the position that, while speed is nice, most of the time you are doing an asynchronous operation anyway, so any overhead from the promise library will matter very little.
[1]: http://research.google.com/pubs/pub40673.html [2]: https://github.com/kriskowal/q/wiki/API-Reference#interfacin... [3]: https://github.com/kriskowal/q-connection [4]: https://github.com/kriskowal/q/wiki/API-Reference#promise-fo...