Earlier quoted context omitted.
One nice thing about "new Promise()" calling the function immediately is that if you are prepared to provide the value immediately then you don't have to return into the runloop, but probably the reason I'd give for why delaying the call would be a horrible idea is that the vast majority of the time the promise is going to do some minimal amount of setup work and then... return to the runloop (and if it isn't, I am g…
No, you won't get the result immediately anyway because then() callbacks are called only on next event loop iteration. This protects from overflowing the stack, but might have small impact on performance.
OK. I see why they would have chosen to do that, and it disappoints me, but it seems to be weirdly more complex than that... this code prints the numbers in order (and continues to do so if you rearrange the calls to setImmediate and setTimeout or move them outside of the function either before or after)... so it is definitely returning from the function but it seems like the resolved value gets to jump the queue?
(async () => {
setImmediate(function() {
console.log("4");
});
setTimeout(function() {
console.log("3");
}, 0);
console.log(await new Promise((resolve, reject) => {
console.log("0");
resolve("2");
}));
})().catch();
console.log("1");