names [Was: Approach of new Object methods in ES5]

Brendan Eich brendan at
Sat Apr 17 09:38:50 PDT 2010

On Apr 16, 2010, at 2:31 PM, David Herman wrote:

> PS Still, I have my doubts about using any such mechanisms for  
> versioning. Incidentally, ROC was just talking about versioning and  
> metadata on the web:

Rob's blog post:

> He wasn't talking about JS API design, but some of the lessons still  
> apply.

Old WHATWG co-conspirators like me obviously agree on the principles  
roc presents, but they do not work so well in JS compared to HTML or  
even CSS. Consider HTML markup:

<video ...>
     <object ...></object>

A new HTML5 video tag with an object tag as fallback, to use a plugin  
to present the video for pre-HTML5 browsers. There are text-y examples  
that work too, even if the degradation is not as graceful as you might  
get with a plugin (plugins can lack grace too :-/).

CSS has standardized error correction from day one, although as noted  
in comments on roc's blog it lacks "feature detection". But graceful  
degradation seems to work as well with CSS as with HTML, if not better.

With JS, new syntax is going to make old browsers throw SyntaxErrors.  
There's no SGML-ish container-tag/point-tag model on which to build  
fallback handling. One could use big strings and eval, or XHR or  
generated scripts to source different versions of the JS content --  
but who wants to write multiple versions of JS content in the first  

The "find the closing brace" error correction idea founders on the  
need to fully lex, which is (a) costly and (b) future-hostile.  
Allowing new syntax in the main grammar only, not in the lexical  
grammar, seems too restrictive even if we never extend the lexical  
grammar -- we might fix important bugs or adjust the spec to match de- 
facto lexical standards, as we did for IE's tolerance of the /[/]/  
regexp literal.

So API object detection with fallback written in JS random logic works  
(for some very practical if not theoretically pretty definitions of  
"works") for the non-syntactic extensions coming in Harmony, assuming  
we can dodge the name collision bullets. But for new Harmony syntax,  
some kind of opt-in versioning seems required.

We survived this in the old days moving from JS1.0 to JS1.2 and then  
ES3. One could argue that the web was smaller then (it was still damn  
big), or that Microsoft's monopolizing helped consolidate around ES3  
more quickly (it did -- IE started ignoring version suffixes on  
<script language=> as I noted recently).

Roc's point about fast feedback from prototype implementations to  
draft standards is the principle to uphold here, not "no versioning".

Obviously we could avoid new syntax in order to avoid opt-in  
versioning, but this is a bad trade-off. JS is not done evolving,  
syntax is user interface, JS needs new syntax to fix usability bugs.  
I'm a broken record on this point.

Secondarily, new syntax can help implementations too, both for  
correctness and optimizations.

So I should stop being a broken record here, and let others talk about  
opt-in versioning. It seems inevitable. We have it already in a  
backward-compatible but semantically meaningful (including runtime  
semantic changes!) sense in ES5 with "use strict".

Opt-in versioning s not a free ride, but it is going to a destination  
we need to reach: new syntax where appropriate and needed for  
usability and productivity wins.

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

More information about the es-discuss mailing list