Andrea Giammarchi andrea.giammarchi at
Thu Aug 8 10:21:15 PDT 2013

tl;dr - I would simply fix `setTimeout 0` ^_^

long story long:
from a suer perspective, I never understood why `setTimeout(fn, 0,
arguments)` does not act as `setImmediate(fn, arguments)` where latter one
is apparently needed to indeed replace a misleading behavior with first
`setTimeout` "broken" call.

IMO, 0 (zero) means "immediate", "asap", on next "tick" ... why should a
user care about bad implementations from vendors? Why vendors should accept
0 at all if 4ms is the minimum? The problem is infinite loop? `for(var i =
arr.length; --i; doStuff);` is still able to "block a thread" so why
`setTimeout` would care? how can `setImmediate` prevent bad designed code
or infinite loops in a way `setTimeout 0` couldn't?

Last but not least: I have no idea why DOM and W3C features should change
anything in current ES specs and I still I don't practically get what makes
setImmediate so special that setTimeout(fn, 0[, arguments]) cannot achieve
resulting in a simplified, unique, way to set timers in JS world and leave
W3C stuff out of the equation.

Best Regards

On Thu, Aug 8, 2013 at 8:06 AM, Forbes Lindesay <forbes at>wrote:

> How about just adding a parameter that tells you whether it was delayed
> for taking too long:
> ```js
> asap(function (tooLong) {
>   if (tooLong) {
>     //attempt to restore invariants here
>   }
>   //do work here
> })
> ```
> And then follow @domenic's solution of just pushing it into the next
> macro-task if it's spent too long executing micro tasks.
> That way users who didn't care about such invariants could just ignore
> that argument and those who do can choose how to handle it gracefully.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list