Promise.resolve().then vs setImmediate vs nextTick
NodeJS 0.11 as well as io.js and the Node 0.12 branch all ship with native promises.
Native promises have a .then
method which always executes on a future event loop cycle.
So far I've been using setImmediate
to queue things to the next iteration of the event loop ever since I switched from nextTick:
setImmediate(deferThisToNextTick); // My NodeJS 0.10 code
process.nextTick(deferThisToNextTick); // My NodeJS 0.8 code
Since we now have a new way to do this:
Promise.resolve().then(deferThisToNextTick);
Which should I use? Also - does Promise.resolve.then
act like setImmediate
or like nextTick
with regards to code running before or after the event loop?
Solution 1:
Using Promise.resolve().then
has no advantages over nextTick
. It runs on the same queue, but have slightly higher priority, that is, promise handler can prevent next tick callback from ever running, the opposite is not possible. This behaviour is an implementation detail and should not be relied on.
Promise.resolve().then
is obviously slower (a lot, I think), because it creates two promises which will be thrown away.
You can find extensive implementation info here: https://github.com/joyent/node/pull/8325
The most important part: Promise.resolve().then
is like nextTick
and not like setImmediate
. Using it n place of setImmediate
can change your code behaviour drastically.
Solution 2:
I'm not going to answer the bolded part about technicalities, but only the question
Which should I use?
I don't think there is any reason to use Promise.resolve().then()
unless you are interested in the promise for the result of your asynchronously executed function. Of course, if you are, then this would be far superior than dealing with callback hell or making a new Promise
from setTimeout
or nextTick
.
There's also a second technical difference, more import than the timing: promises do swallow exceptions. Which you probably don't want. So, like @vkurchatkin mentioned, don't create promises only to throw them away. Not only because it's slower, but because it makes your code less readable and your app more error-prone.