Bringing setTimeout to ECMAScript

David Bruant david.bruant at
Fri Mar 18 19:18:25 PDT 2011

Le 19/03/2011 00:26, Brendan Eich a écrit :
> On Mar 18, 2011, at 9:25 AM, Wes Garland wrote:
>> Two things off the top of my head to consider:
>>  - timer granularity
> This is an interop issue, mostly due to stupid benchmarks that degenerate to measuring whether the browser clamps at 10ms or 4ms. It is also now a standard: 4ms.
> Various implementors have found that setTimeout(f, 0) that calls f immediately "breaks the web" (or at least the New York Times site). Similarly, waiting an event loop turn seems to break the web. By testing, 4ms has been arrived at. I welcome fresher data.
As I said, one way to bring setTimeout would be to standardized a
lower-level mechanism based on which setTimeout could be implemented.
Maybe that this timer granularity could be reconsidered for the
lower-level mechanism. Maybe that this lower-level mecanism could count
nanoseconds (I'm purposefully exagerating).
Moreover, maybe that a standardized setTimeout could leave some
implementation-defined room. For web browsers, 4ms as a minimum may have
become a standard, but maybe that node.js or other ES-based languages do
not care about this de-facto standard since they don't have to be
interoperable with web browser code.

>>  - forbidding eval-like syntax
> What problem are you solving?
I would agree to forbid eval-like syntax. Of course, it would be stupid
to do forbid such code in general since it's already in use. However, it
could be forbidden in strict mode (but as said in my first e-mail, with
FF4 shipping in 3 days with strict mode, without forbidding, it may be
too late to consider such an option. If it is not, please tell so). If
people trigger Harmony code by an opt-in, maybe we can catch that train.

The problem I see and that I would like to solve would not be technical
at all, it would educational.
Currently, people can do eval, they can pass strings as handlers to HTML
attributes (with the famous "return false;") or through JS by assigning
the myDiv.onclick property. They can use strings in setTimeout. They can
decide to never use anonymous function and be in complete denial of
ECMAScript being a functional language.
However, if we bring setTimeout to ECMAScript Harmony, we can have the
ability to say to people "please use functions instead of strings for
setTimeout in Harmony code" (the last part is important to not break
existing code). This could be a first step in explaining that functions
can be something else. And let's face it, it's not a big step, it's just
de-quoting and wrapping with function(){ ... } (or even #(){...} ?).
With good error messages it will help people transitionning quickly and
learning something on the way.
The best argument I can give on functions being better than strings is
code anyoneI have written at the very beginning. I used a string in
setTimeout and was creating it dynamically with the value of some
variable. this is hard to maintain, probably hard to optimize for the
engine. With a function, you just use capture the variable value withing
the function used as a closure. No maintainability issue, no problem to

That's my only opinion and it's fine if nobody agrees but at least it is


More information about the es-discuss mailing list