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 <[email protected]>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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
