On Thu, Jun 25, 2015 at 12:09 AM, Todd Reifsteck <toddr...@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
