Skip to main content

Return to Answer

added 17 characters in body
Source Link
Bergi
Bergi
  • 670.7k
  • 162
  • 1k
  • 1.5k

The other answer proves this, but let me talk about the reasoning:

Promise constructor

The promise constructor callback (as specified either in the ES6 spec or the constructor spec libraries implement) will always be executed synchronously - this is in order to extract a deferred (older form of promise construction) out of it in case you need to have access to the resolve callvackcallback:

var r; var p new Promise(function(resolve, reject){ r = resolve; }); // use r here, for example arr.push(r);

then callbacks

then will always be executed asynchronously, virtually all mainstream promise implementations (Native, bluebird, $q, Q, when, rsvp, promise, jQuery (as of 3.0) etc) as well as native promises implement, or (or implement a superset (moreof, with more constraints) implement Promises/A+.

The reasonThis is exactly the reason that Promises/A+ was created out of Promises/A exactly for this reason. So that asynchronousAsynchronous guarantees will be preserved and Zalgo won't be released. (Also see this post).

The fact this happens (asynchronous guarnateeguarantee) is completely intentional and actively prevents race conditions. Code in- and outside of then will always execute in the same order.

Here is the relevant quote:

onFulfilledonFulfilled or onRejectedonRejected must not be called until the execution context stack contains only platform code. [3.1].

The other answer proves this, but let me talk about the reasoning:

Promise constructor

The promise constructor callback (as specified either in the ES6 spec or the constructor spec libraries implement) will always be executed synchronously - this is in order to extract a deferred (older form of promise construction) out of it in case you need to have access to the resolve callvack:

var r; var p new Promise(function(resolve, reject){ r = resolve; }); // use r here, for example arr.push(r);

then callbacks

then will always be executed asynchronously, virtually all mainstream promise implementations (Native, bluebird, $q, Q, when, rsvp, promise, jQuery (as of 3.0) etc) as well as native promises implement, or implement a superset (more constraints) implement Promises/A+.

The reason Promises/A+ was created out of Promises/A exactly for this reason. So that asynchronous guarantees will be preserved and Zalgo won't be released. (Also see this post).

The fact this happens (asynchronous guarnatee) is completely intentional and actively prevents race conditions. Code will always execute in the same order.

Here is the relevant quote:

onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1].

The other answer proves this, but let me talk about the reasoning:

Promise constructor

The promise constructor callback (as specified either in the ES6 spec or the constructor spec libraries implement) will always be executed synchronously - this is in order to extract a deferred (older form of promise construction) out of it in case you need to have access to the resolve callback:

var r; var p new Promise(function(resolve, reject){ r = resolve; }); // use r here, for example arr.push(r);

then callbacks

then will always be executed asynchronously, virtually all mainstream promise implementations (Native, bluebird, $q, Q, when, rsvp, promise, jQuery (as of 3.0) etc) as well as native promises implement (or implement a superset of, with more constraints) Promises/A+.

This is exactly the reason that Promises/A+ was created out of Promises/A. Asynchronous guarantees will be preserved and Zalgo won't be released. (Also see this post).

The fact this happens (asynchronous guarantee) is completely intentional and actively prevents race conditions. Code in- and outside of then will always execute in the same order.

Here is the relevant quote:

onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1].

Source Link
Benjamin Gruenbaum
Benjamin Gruenbaum
  • 277.6k
  • 90
  • 524
  • 524

The other answer proves this, but let me talk about the reasoning:

Promise constructor

The promise constructor callback (as specified either in the ES6 spec or the constructor spec libraries implement) will always be executed synchronously - this is in order to extract a deferred (older form of promise construction) out of it in case you need to have access to the resolve callvack:

var r; var p new Promise(function(resolve, reject){ r = resolve; }); // use r here, for example arr.push(r);

then callbacks

then will always be executed asynchronously, virtually all mainstream promise implementations (Native, bluebird, $q, Q, when, rsvp, promise, jQuery (as of 3.0) etc) as well as native promises implement, or implement a superset (more constraints) implement Promises/A+.

The reason Promises/A+ was created out of Promises/A exactly for this reason. So that asynchronous guarantees will be preserved and Zalgo won't be released. (Also see this post).

The fact this happens (asynchronous guarnatee) is completely intentional and actively prevents race conditions. Code will always execute in the same order.

Here is the relevant quote:

onFulfilled or onRejected must not be called until the execution context stack contains only platform code. [3.1].