jQuery vs. Promises/A
In terms of capabilities, jQuery Promises and Promises/A are nearly identical. Q.js, the most popular Promises/A library, even offers methods that can work with jQuery Promises. The differences are superficial; they use the same words to mean different things.
As previously mentioned in Making Promises, jQuery uses the term resolve as the opposite of fail, whereas Promises/A uses fulfill. Under Promises/A, a Promise is said to be “resolved” when it’s either fulfilled or failed.
Up until the release of 1.8, jQuery’s then method was just a shorthand for invoking done, fail, and progress simultaneously, while Promises/A’s then acted more like jQuery’s pipe. jQuery 1.8 corrected this by making then a synonym for pipe. However, any further reconciliation with Promises/A is unlikely because of backward compatibility concerns.
There are other, subtler differences as well. For instance, in Promises/A, whether a Promise returned by then is fulfilled or rejected depends on whether the invoked callback returns a value or throws an error. (Throwing errors from jQuery Promise callbacks is a bad idea because they’ll go uncaught.)
Because of these issues, you should try to avoid interacting with multiple Promise implementations in the same project. If you’re just getting Promises from jQuery methods, use jQuery Promises. If you’re using another library that gives you CommonJS Promises, adopt Promises/A. Q.js makes it easy to “assimilate” jQuery Promises.
| | var qPromise = Q.when(jqPromise); |
As long as these two standards remain divergent, this is the best way to make them play nice together. For more information, see the Q.js docs.[35]