On Thu, Jun 25, 2015 at 12:09 AM, Todd Reifsteck <toddreif@microsoft.com>
wrote:
> The setImmediate spec does not sufficiently explain that it is intended
> NOT to run in that situation. If IE/Microsoft Edge are tested, this can be
> observed.
>
I think this is the key point of confusion, and it seems to be a commonly
shared one. For example, Nicholas's article [1] compares setImmediate to
node's nextTick, which has very different semantics from what's implemented
in IE and what we want from requestIdleCallback.
Thinking out loud... I guess one approach would be to clarify the behavior
in existing setImmediate spec:
+ existing setImmediate adoption works on more browsers
- the behavior may be *very* different from what authors thought they're
getting [2]
- the name does not match the intent and is a barrier and point of
confusion for new adoption
Alternatively, we can define a new API:
+ name clearly communicates the intent (insert bikeshed here)
+ we're free to change the shape and behavior of the API.. blank slate.
- need to drive new adoption; BUT, we could polyfill existing setImmediate
in terms of this new API
FWIW, personally I think the new API route is a better long-term investment.
ig
[1] http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/
[2] https://github.com/w3c/setImmediate/issues/2