Bringing setTimeout to ECMAScript

Boris Zbarsky bzbarsky at MIT.EDU
Sun Mar 20 13:05:15 PDT 2011

On 3/20/11 1:55 PM, John J. Barton wrote:
> On 11:59 AM, Boris Zbarsky wrote:
>> Nowadays the clamp is there because sites use |setTimeout(f, 0)| when
>> they really mean "run this at 10Hz" and if you run it with no delay
>> then they swamp your event loop and possible render "wrong" (e.g. the
>> text disappears before the user has a chance to read it).
> I'm not convinced that this is the meaning. I use |setTimeout(f, 0)| to
> mean "schedule f after this event completes"

_You_ do.  Some sites do that.  A lot of other sites mean "oh, just do 
it the way it looks to me when I test it in this one browser I bothered 
to test with".

> I think that is the common meaning.

Both meanings are very common.  If you're claiming that one is more 
common than the other, I'd like to see some data.

In any case, both meanings are common enough that breaking either one 
significantly is not an option.

Again, Chrome tried to make setTimeout(f, 0) run after no more than 1ms, 
and discovered that sites "break" whatever that means.

> We assume (without real evidence I suppose)

Yep, definitely without evidence.  ;)

> The essential logic of |setTimeout(f, 0)| is cooperative multiprocessing
> yield: we believe that our current event processing could be long enough
> to interfere with user interaction and |f| can be delayed without
> serious impact on the UI. We have no reason to pick a value other than
> zero. If we want to give the user 3 seconds to read text we use 3000.

1)  You would be surprised at what web pages do, re your 3000 thing.
2)  "yield" is not good enough if each execution of your timeout takes
     an appreciable amount of time.  For example, if your execution is
     10ms but you schedule the timer to run every 2ms, you _will_ swamp
     the event loop.  84% of the time or so things will be nonresponsive.

> The "swamp the event loop" case is logically unrelated to this case,

Not at all.

> just like setInterval is unrelated. Multiple repeated calls to
> |setTimeout(f,0)| are bugs and setInterval of zero would be a bug.

Those are the cases that get clamped.  If you just setTimeout(f, 0) when 
not inside a timeout, you don't get clamped.

> Of course the browser has to deal with theses cases, but the lower limit on
> setTimeout seems like crude solution.

It's the one browser makers have all implemented.


More information about the es-discuss mailing list