Use jQuery or Q.Js for promises

Question

I'm looking into BreezeJs and there samples are using Q.js for promises to handle asynchronous calls. John Papa is also using Q. JQuery has promises as well. What are the differences between the two?

Assizes

Just my $.02. I work on breezejs and looked at both jQuery and Q before selecting Q for our promise implementation. At the time, I tried to see what other library authors were using and why. My conclusion was that Q was being selected overwhelmingly, partially because it was an independent library without the weight of jQuery, but also because there were a number of subtle but annoying differences between the jQuery implementation at that of Q, where jQuery's implementation was not strictly Promises/A or Promises/B compliant. – Seigniory

As a side note, I've since noticed that google created an embedded version of Q to use within angularjs. – Seigniory

The big difference that swayed me to use Q in some cases is that when I simply needed promises, Q fits nicely while jQuery is so much more. So Q is lightweight when all you need is promises. But when I use jQuery too, which is often, I use jQuery's promises since I already have them at my disposal. In other words, both are excellent :) – Kitchen

I recommend neither Q nor jQuery if you want good performance, have a look on github.com/petkaantonov/bluebird can see here the benchmark: github.com/petkaantonov/bluebird/blob/master/benchmark/stats/… – Tickle

Answer 1

Both are based on the Promises/A standard and implement a then method (though only current jQuery, they once had a incompatible pipe instead of then). However, there are a few differences:

• Q has exception handling. All thrown errors in the async then callbacks will be caught and reject the promise (and will only get re-thrown if you call .end()). Not sure whether I personally like that. It's the standardized way which jQuery does not follow, rejecting from then in jQuery deferreds is much more complicated.
• Q promises are resolved with a single value/reason (like you return/throw it from then), while jQuery allows multiple arguments in resolve/reject calls on its Deferreds.
• Q has lots of Proxy methods which will allow you to modifiy future values
• Q has .all and similiar, which are more complicated with jQuery ($.when.apply($, […])).
• Q does explicitly work with ticks in the event loop and guarantees asynchronity, while jQuery can be synchronous as well. This is now required by the Promises A/+ specification.

… which is basically Promises/B. As you can see, the Q API is more powerful, and (imho) better designed. Depending on what you want to do, Q could be the better choice, but maybe jQuery (especially if already included) is enough.

Berseem

The exception handling thing is the one thing that's putting me off Q too. In my opinion exceptions should only be used for things which are unexpected and not for regular errors. Exception handling is too heavyweight, several orders of magnitude slower than passing around error codes etc. – Rag

jQuery does not implement Promises/A: domenic.me/2012/10/14/youre-missing-the-point-of-promises – Surroundings

@Domenic: Thanks for the correction, it's time to update the post. What I meant was that jQuery was based on Promises/A - I know that is has some serious issues. – Berseem

This answer is two years old+, things haven't changed since? – Sacksen

@Vadorequest: Not really. There are pull request on jQuery to make it A+ compatible, but afaik they haven't been accepted yet - there still are multiple problems. The only thing that has changed in the last years is that Q has been mainly superseeded by other, even more powerful promise libraries :-) – Berseem

Is all still true with current versions in 2017? Or has the topic become obsolete because of other technologies? – Emoryemote

@Emoryemote While jQuery 3 has adopted Promises/A+ (error handling), $.when is still horrible to work with. And yes, they've been become pretty much obsolete in modern browsers that come with native ES6 promises. – Berseem

Answer 2

JQuery's promise implementation of the Promises/A spec has some real issues. The following link describes them far better than I can: missing-the-point-of-promises

Seigniory

+1 for article reference. I had read that article before. Finally solidified my understanding of Promises and what was different with the JQuery spec. – Semipalmate

That article is great, but requires a couple of reads. I did miss the point of promises for sure. The exception handling part. – Chiastic

Answer 3

Bergi's answer covers things fairly well. I wanted to add, though, that we've created a guide for Q users coming from jQuery. To summarize the relevant sections:

• Q handles exceptions, allowing you to handle all errors through a uniform interface.
• Q focuses on chaining with all its methods, whereas jQuery only allows chaining from then/pipe.
• Q promises guarantee asynchronicity, thus avoiding the control flow hazards and race conditions that result from jQuery's sometimes-sync, sometimes-async behavior.
• Q promises are always fulfilled with a single value or rejected with a single reason, just like synchronous functions always either return a single value or throw a single exception.
• Q enforces a separation between the deferred and the promise, whereas jQuery merges them into one object with the option of separating them.
• Q does not track a context object along with the fulfillment or rejection, since this has no parallel for synchronous functions (i.e., you never return a value as well as a this in which the caller must run). So there is no resolveWith or rejectWith.
• Q uses Promises/A+ terminology; the main difference is that Q uses "fulfilled" where jQuery uses "resolved," and in Q "resolved" means something more subtle.

The guide also contains a table paralleling jQuery and Q promise APIs.

Surroundings