Shouldn't timers be specified?

Brendan Eich brendan at mozilla.org
Sun Jan 22 19:33:28 PST 2012


> Jorge <mailto:jorge at jorgechamorro.com>
> January 22, 2012 1:35 PM
>
> Now isn't that ~ the opposite of what you said on 2011-03-18 in David 
> Bruants' "Bringing setTimeout to ECMAScript" thread ?

Is this a "gotcha" game? Notice the date. Our cutoff for ES6 features 
was 2011-05. That's one thing that changed. But also, try to read more 
carefully:
>
> <quote>
> Add to that the fact that Netscape and Microsoft failed, or chose not 
> to, standardize the DOM level 0, and we have the current split where 
> setTimeout is in HTML5 but the core language is embedded with 
> increasing success in non-browser, no-DOM host environments *that want 
> setTimeout*.
>
> I'm open to Ecma TC39 absorbing setTimeout and the minimum machinery 
> it entrains. We should ping Hixie.

Nothing, and I mean *nothing*, that I wrote here contradicts what I 
wrote in reply to Brandon. Ecma TC39 is almost certainly going to absorb 
event loop, timeout, and other specs from the WHAT-WG / W3C (or 
duplicate them).

Why do you insist on taking one thing I wrote and misreading it as 
contradicting another thing (namely, timing re: ES6, Node's 1ms vs. 
HTML5's 4ms lack of agreement indicating more synthesis needed, etc.)?

> </quote>
>
> Why ?
> What has changed ?
>
> P.S.
> Node.js does *not* conform. Not at all. Not only it doesn't clamp to 
> 4ms (which happens to be a good thing, IMO), but its timers often fire 
> out of order !

Here you clearly misread my reply to Brandon -- I was citing modern 
browsers' clamping at 4ms, per HTML5, in contradiction to Node's 1ms as 
cited by Brandon.

But I didn't know Node does not preserve FIFO order. That seems like an 
easy bug to fix. Is it on file, do you know?

/be


More information about the es-discuss mailing list