ES6 opt-in, reloaded

Herby Vojčík herby at
Tue Jan 17 05:20:34 PST 2012

Andreas Rossberg wrote:
> On 16 January 2012 23:18, David Herman<dherman at>  wrote:
>> The goal that is missing, and what I believe is the single most
>> important part of my New Year's email, is:
>> 9. Allow programmers to continue thinking of JS as a single
>> cohesive language.
>> This is a relative concept rather than an absolute one, but it has
>> real practical consequences on the overall cognitive complexity of
>> the language. If you look at the terminology we've been using in
>> TC39 for years, we either talk about multiple "modes" of JS, or
>> even talk about ES6 as if it's "the new language." I believe this
>> has been a mistake. Now, we've always agreed that ES6 must
>> necessarily subsume ES5. And you might claim that this was just
>> imprecise and casual speech, but I think it betrays a flawed
>> assumption: that ES6 gives us leeway to make clean breaks with the
>> past.
>> [...]
>> Instead, we should hew as close as possible to an ideal of One
>> JavaScript, knowing that we'll never be perfect. But -- I believe
>> -- we can get pretty darn close.
> ...
> With your proposal, you give the current generation of programmers
> the illusion that ES6 is a simple extension of ES5. But all future
> programmers, who grow up with ES6 or beyond, will still have to deal
> with the legacy of ES5 non-strict mode. There will be two modes to
> worry about forever after (unless we make another breaking change).
> Refactoring pitfalls will persist.
> What I envision makes the transition somewhat more explicit for
> current programmers (ideally, they need to write at most one extra
> keyword). But anybody who starts development with ES6+ will never
> have to care about modes again. For her/him, extended mode is all
> that's relevant. Refactoring pitfalls only arise during initial
> version transition.
> I claim that on the long run, the latter will converge much closer
> on the ideal of One JavaScript. With your proposal, you are
> essentially trading perceived simplicity (which, as an aside, is
> factual complexity) for current JS programmers for increased
> complexity for all future JS programmers.

I agree with this. I think only a few things should be added to ES5 
non-strict (destructuring, new object literal, .{...}, <| {...}, maybe 
something more) and one and only one opt-in to ES6 should be module 
{...}, eventually "use module;" or similar non-bracing implicit 
module-wrapper form at the beginning of program (which can be trivially 
taken care by concat-builders by wrapping such program in module { ... 
}; it assume the "use module;" form is otherwise silently ignored inside 
proper module and is syntax error outside it except as a first thing in 
program). Nothing else (class in ES5 non-strict is syntax error etc.)

This keeps it simple and does not force you to move to ES6 for small 
useful details, only for more serious new functionality.

> You make a good point with JS code in HTML attributes, though. I
> don't have a good answer for that, except falling back to a meta tag.
> For that specific purpose, that might be fine.
> /Andreas


More information about the es-discuss mailing list