brendan at mozilla.org
Mon May 19 13:53:22 PDT 2008
On May 18, 2008, at 1:17 AM, Brendan Eich wrote:
> On May 17, 2008, at 9:00 PM, Mark S. Miller wrote:
>> On Sat, May 17, 2008 at 8:54 PM, Brendan Eich <brendan at mozilla.org>
>>> No, we want a number line that goes up sensibly. JS3.1 if it
>>> follows 1.7
>>> would have everything on board for ES3.1 + other stuff not in ES3
>>> prefigures ES4.
>> I couldn't parse that. Could you restate?
> JS version number line:
Wrapped badly by mailman. Shrinking horizontally:
1.0 1.1 1.2 1.3 1.4 ES3 1.5 1.6 1.7 1.8
basis for ES1 close to ES2
> Now, where does "JS3.1" go? If it's exactly the same as anything like
> what's proposed for ES3.1, it does not fit on the number line above.
> The line must fork somewhere between ECMAv3 and 1.6 (inclusive),
> since ES3.1 as proposed does not have much (if anything) from JS1.7
> or 1.8. The line must fork, because there are things in ES3.1 not in
> any version on the line above.
Not sure if lack of replies means I was unclear, but the above number
line should help highlight an awkward truth: ES3.1 is a step sideways
(and in some ways backward) for "JS" as represented by Mozilla's
implementations (Rhino is tracking SpiderMonkey). That's ok,
standardizing post-hoc can be good (making up new stuff for 3.1 is
less clearly good in this light -- more work needed to uphold the
ES3.1 < ES4 subset relation).
Since JS has evolved ahead of the standard since 1999 (and did before
then, resulting in ES1 and ES2), a "JS3.1" does not make sense. Any
ES3.1 standard would be folded into JS2 or possibly JS1.9 (the
numbers are decimals, so 1.10, 1.11, etc. are possible too, but
unlikely in my opinion).
Separately from "JS3.1", my belief is that jumping from JS2 to JS4 is
not helpful to "half" the audience (not truly half; who knows? could
be by far the majority, since "ECMAScript", .es suffix, etc. have not
caught on) who think in terms of the JS1.x evolution, however much it
might help those focused on the ES numbers.
It's hard to argue strongly for either "half" since I claim so little
is at stake in terms of confusion. If we end up seeing <script
I'll eat my words.
I rather suspect we will see untyped or default-typed script tags
continue to dominate, and some amount of user-agent sniffing used
server-side to deliver JS2/ES4 code to up-rev clients. I would bet
real money that the .js suffix and the unversioned "application/x-
More information about the Es4-discuss