ES6 opt-in, reloaded

Andreas Rossberg rossberg at google.com
Mon Jan 16 08:09:51 PST 2012


Some of the recent discussion regarding ES6 opt-in has been rather...
scary. I would like to step back a bit, and try to identify the goals
that we actually want to achieve. I think these are:

1. Make ES6 opt-in as convenient as possible.

2. Avoid reliance on external features like script tags or mime types.
(Not all JS is on web pages anyway!)

3. Provide as many incentives for switching to ES6 as possible.

4. Minimize necessary changes in programming style.

5. Minimize ES5-ES6 transitioning pitfalls.

6. Avoid maintenance or refactoring pitfalls in ES6 itself. Avoid that
ES6 programmers have to think about modes or feature sets at all.
(This particularly should apply to non-savvy programmers!)

7. Minimize semantic complications (which tend to harm both
implementations and programmers).

8. Obviously, achieve full backwards compatibility.

The various proposals in the thread were primarily aimed at (1), but
AFAICS all fail on (6), to different extent. (There were mixed results
for the other points.) Consequently, programmers would have to be
aware which features put them into ES6 (and thus strict mode), and
which are only available there, and that local changes could subtly
change the meaning of unrelated program parts (due to strict mode), or
even the whole program. Moving code could subtly change its internal
meaning.

It's also worth noting that backporting new ES6 features to classic
mode, as has been proposed by several people, clearly works against
(3), and consequently, also against (5/6). Similarly, opting in at
smaller scope, as has also been discussed, is a blatant violation of
(6) and (7), and works against (3), too.

So I have plea: let's keep it simple. Start from the simplest of all
possible ideas and optimize from there. That is, opting into ES6
through one simple declaration on the top of a program (and nowhere
else). Otherwise it's ES5 unchanged. As far as I can see, that clearly
wins, or is no worse than other proposals, on anything but (1).

Compared to Dave's original proposal, the only scenario on which it
loses re (1) is if the program already consists of a module, in which
case you'd still have to write the opt-in declaration. One can
probably argue whether this is worth adding an extra rule (personally,
I don't think so). If so, it would be enough to say that a module
declaration as the _first_ statement in the program also opts in _all_
of the program.

In either case:

1. You always opt in all of the program consistently.
2. It is obvious from the first line that you do.
3. This truly opts-in the toplevel (for whatever that means in detail).
4. A future ES programmer just needs to know one rule: start your
program with _____.

(I'm intentionally avoiding bike-shedding a concrete syntax for ____ here.)

And before somebody brings it up: I do not fear that this will share
the fate of strict mode, because there actually is plenty of incentive
for using ES6 (especially, if we do _not_ extend classic mode).

/Andreas


More information about the es-discuss mailing list