Bringing setTimeout to ECMAScript

Brendan Eich brendan at
Sat Mar 19 15:50:33 PDT 2011

On Mar 19, 2011, at 3:16 AM, Peter van der Zee wrote:

> On Sat, Mar 19, 2011 at 1:13 AM, Brendan Eich <brendan at> wrote:
> On Mar 18, 2011, at 5:54 AM, Peter van der Zee wrote:
>> +1 to standardizing the timer family.
>> I always thought this wasn't in because the specification didn't have any asynchronism and specifying timers would open Pandora's box.
> How so? I created JS and its run-to-completion execution model and setTimeout all at once in 1995. It has not changed in execution-model semantics since.
> I can't think of a single way to simulate setTimeout in ES5. Correct me if I'm wrong, but I don't think ES5 exposes a single way of defining a mechanism like:
> --
> var x = 4;
> function f(){ x = 5; print(x); }
> timer(f, 1);
> print(f);
> --
> Such that it would output 4 before 5. That's what I meant with "didn't have any asynchronism", fwiw.

That's not the same as "open[ing] Pandora's box".

Let's not use asynchronism loosely. "Asynchronous I/O" can mean threads and completion ports. It means shared-memory threads and non-determinism in general.

setTimeout does not introduce threads, shared memory among them, or even non-determinism if we spec carefully (browsers have to implement carefully already).

> The issues with setTimeout have more been about "core langage" vs. "DOM level 0", and the lack of a "DOM level 0" standard prior to HTML5.
> What do you mean by that? Why should that influence the choice of including it in the ECMA spec? What about embedded environments or ssjs?

Exactly my point: the historical accidents of what got spec'ed in which standards body, or not spec'ed at all for years, should not overrule other criteria now. If we want to spec setTimeout and event loopage in Ecma TC39, we can consider it on its merits.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list