setTimeout to async-ify require([]) form's choice of 15ms sounds overkill

[requirejs]

setTimeout to async-ify require([]) form's choice of 15ms sounds overkill

[jrburke]

As I recall browsers downgrade setTimeout(0) to a minimum, I believe setTimeout(4). The 15 was really just a cultural holdover, somewhat arbitrarily picked. I'm open to reducing it. I'm wary of the postMessage approach as I thought there was a pathological case for it, but I cannot find the link at the moment. Plus, almond runs in non-postMessage browsers.

So I'm open to a few things:

• just set the timeout lower. 0 still bothers me, maybe 1 or 4?
• a postMessage branch if we can get it small. I'll look more into this today, try to find the bad case I heard for it.

I also want to understand where the use case where this starts to cause a significant delay. If this is for initially creating a public, "browser globals" API at the end of an almond-built file, then synchronous require('id') can be used to immediately get the module value you want to make public.

If it is about using internal require([], function(){}) calls inside a module, that happen on regular intervals, I can see making that faster as useful. I can also see where a few of these calls stacked up together (maybe for loader plugins?) makes the overall wait longer than it should be for first initialization.

I keep wishing setImmediate or something like it was available everywhere.

[asutherland]

WHATWG says http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-settimeout:
4. Let timeout be the second argument to the method, or zero if the argument was omitted.
5. If the currently running task is a task that was created by the setTimeout() method, and timeout is less than 4, then increase timeout to 4.

I have no clue what the crappy end of the supported spectrum does; I think that's mainly based on what webkit had been doing for a while and then Firefox adopted. (Firefox was 10ms for a while, I believe.)

I think setting a lower value and adding a comment like:
// using a non-0 value because of concern for what old browsers do; use require('module') to avoid this

That seems like an overall net win since it's a smaller value and if someone uses a profiler and is wondering what's up with that setTimeout, it should become clear to them and they will immediately know the workaround. But it does add a line of text. Your call!

[jrburke]

Pushed a change with your suggestion. If you would like a point release done (0.2.4), I can do that too.

[asutherland]

Point release not required; we're going to use the workaround. Thanks for the offer, though!

[jrburke]

OK, I pushed 0.2.4 anyway, did not have anything else in the queue/triage and did not want the code languishing without a release.