Sorry to be coming into this discussion a bit late, but I'd like to point out one idea which seems to have gone unmentioned during the furious debate, and which merits keeping in mind as promises come into wider spread use:
My sense is that many in the JS community seem to regard promises principally as an abstraction for dealing with asynchrony. While they certainly *are* that, the original driving use case for their invention/adoption (when I first encountered them, 25 or so years ago) was as an abstraction for dealing with network latency, and I believe this consideration loomed large in the minds of some of the TC39 committee members who championed the adoption of the ES6 Promise API in its current form. In contrast to many of the closure-based callback mechanisms which have been brought up variously as alternatives to promises or as sugarings or implementations of them, one of the great virtues of promises is that they can be pipelined. In particular, they can be pipelined over the network when invoking operations on remote objects, which means that a sufficiently clever or aggressive implementation can speculatively deliver requests over the network to the result of an earlier request b efore that result has been determined, potentially short circuiting one and potentially many network round trips. This can yield substantial (several orders of magnitude, in some cases) speedup to some kinds of heavily networked applications. This is easy to lose track of if you're just thinking of promises as a different notation for writing callbacks. Chip _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
