ES6 opt-in, reloaded

Andreas Rossberg rossberg at
Tue Jan 17 04:51:36 PST 2012

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.

Thanks for that, I think we are getting to the core of our
disagreement. It is kind of funny, because my goal is exactly the
same, but from a different perspective.

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

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.

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.


More information about the es-discuss mailing list