No more modes?

Dmitry A. Soshnikov dmitry.soshnikov at
Mon Oct 18 03:17:44 PDT 2010

  (At last I've read this thread; I'll answer not for this exact letter, 
but in general).

So, there are two backward compats issues:

1. Running an old code (with possible naming conflicts such as `let`, 
`const`, etc) in a new (ES6) engines; thus, there is no new syntax involved;
2. Running new code in the old engines (the issue with a new syntax).

For the first sub-problem a `use harmony;` directive can be enough. This 
also will work in non-browser host environments (such as CommonJS / 

However, in a view of exactly a pragma directive (i.e. not as a "use 
strict"; string literal) it will cause the second issue, i.e. a syntax 
error in all browsers (just right at the first line because they won't 
be able to parse this pragma). But, being in the "use harmony"; view (as 
a string literal) also won't solve the issue. Because old browsers even 
if won't fail on the first line, will do it later when find a new syntax 
(because the code will be ran anyway).

So for exactly old browsers the approach with:

<script type="harmony">

seems good (if not the only possible) since this block won't be even 

And for server-side JS -- there the approach a little different: the 
same the new code in old engines won't work -- syntax errors (and seems 
there are no other obvious ways to prevent it besides checking the 
MAX_ES_VERSION and require(...) dynamically needed code). But more 
likely, on the server side it's cheaper and easier to update the engine 
which support the new syntax (thus, even "use harmony;" isn't needed -- 
so <script type="harmony"> seems wins -- because the issue mostly 
touches exactly browser host environments).

P.S.: and experiments with <script-if-else> may be leaved for more 
needed cases.


On 15.10.2010 21:30, Brendan Eich wrote:
> On Oct 14, 2010, at 3:47 PM, Brendan Eich wrote:
>> Seriously, we don't want a version lattice with bad combinatorics. 
>> We've been over this in TC39 meetings and there are records on the 
>> wiki. The prominent memento is 3(I) at:
> Prior to Means 3(I), there is Goal 4 
> (
>  Keep versioning as simple and linear as possible.
> We don't have concrete plans for a "use strict" in Harmony to opt into 
> a "stricter than ES5 strict" mode. The "no more modes" plea is good as 
> far as it goes (just not absolute), so I hope we do not add any such 
> Harmony-strict-mode. We're really trying not to make an N-dimensional 
> version/mode/pragma lattice.
> But, again, ES5 makes incompatible (slight) changes to the de-facto 
> standard JS ("ES3R") language, and ES5 strict is indeed a mode. New 
> syntax is coming, but we will build it on ES5 strict under some kind 
> of opt-in.
> The minimum opt-in mechanism, we think, is specified by RFC4329: 
> <script type="application/ecmascript;version=6">. This works in IE9, 
> in the sense that the script tag content is not processed (thanks to 
> Jeff Walden for testing). Testing in older and other browsers 
> welcome,with and without the ;version= parameter.
> Markup-based version selection, to allow inline, out of line (src=) 
> with prefetching, and downrev-browser fallback without 
> "autoconf-style" generation of script elements, seems worth considering.
>>> - Will we have to add yet another mode each time we add syntax? 
>>> After enough iterations this becomes unsustainable.
>> Languages don't grow indefinitely but JS syntax (and semantics) are 
>> gappy enough there could be another edition that comes after the 
>> first Harmony edition.
> That was a bit too neutral-sounding.
> I want to add that my strong desire is to avoid adding syntax after 
> the "Harmony edition" (let's hope it is ES6, but we have been burned 
> picking numbers prematurely in the past, and there's no need yet to 
> pick a number). I'm simply skeptical about our ability to predict the 
> future or enforce a bad prediction.
> Modules should give everyone writing libraries (least of all TC39) 
> name-conflict-free upgrade paths, along with lexical scope all the way 
> up (no global object). If we ever get to the promised land of macros, 
> we'll need modules (and a lot else; macros are very much a dark horse, 
> or just a gleam in my eye).
> So modules are important. Proxies too. So are 
> let/const/function-in-block. Some less critical but worthwhile 
> conveniences matter too, enough that they're in the harmony section of 
> the wiki.
> If you ask me, the list outlined in the last paragraph is enough for 
> "Harmony". I'm not sure we need classes or traits in the language; 
> more work (under way) is needed to find out.
> My two cents, and as usual I reserve the right to change my mind, or 
> coins.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at

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

More information about the es-discuss mailing list