Promises have existed in many forms in many languages. The term was first used by C++ engineers on the Xanadu project, a forerunner to the Web. Promises were later used in the E programming language, which inspired Python developers to implement them in the form of the Twisted framework’s Deferreds.
Promises hit the JavaScript mainstream in 2007 when the Dojo framework, taking a cue from Twisted, added an object called dojo.Deferred. At the time, the relatively mature Dojo rivaled the fledgling jQuery framework in popularity. In 2009, citing dojo.Deferred as an influence, Kris Zyp proposed the CommonJS Promises/A spec.[31] That same year, Node.js made its first appearance. Node’s early iterations used Promises in its nonblocking API. However, in February 2010, Ryan Dahl made the decision to switch to the now-familiar callback(err, results...) format, on the grounds that Promises are a higher-level construct that belongs in “userland.”
This decision made way for competing Promises implementations aimed at Node, notably Kris Kowal’s Q.js[32] and AJ ONeal’s Futures.[33] (In common usage, the terms Promise, Deferred, and Future are roughly synonymous.) Q is a fairly straightforward implementation of the Promises/A spec. Futures is a broader toolkit, incorporating many of the flow control features found in libraries like Async.js.
But the reason Promises are getting so much attention today is, of course, jQuery. Accompanying a major rewrite of $.ajax in January 2011, jQuery 1.5’s Promises implementation thrilled countless developers who were encountering Promises for the first time. Others, however, were frustrated that the Promises/A spec had been ignored, leading to subtle API differences.
We’ll focus on jQuery Promises for the rest of this chapter, except in jQuery vs. Promises/A. We’ll also take our vocabulary cues from jQuery, particularly the distinction between Deferreds and Promises that we’ll see in the next section and the use of “resolve” as the antonym of “reject.”
3.16.79.146