ES6 opt-in, reloaded

David Herman dherman at mozilla.com
Mon Jan 16 14:18:06 PST 2012


On Jan 16, 2012, at 8:09 AM, Andreas Rossberg wrote:

> 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 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.

ES6 should not fork JS into two separate and (over time) diverging dialects. The cost to developers would be too great. Ask a web developer, and I bet you 9 times out of 10 they will agree. Certainly the ones I've talked to so far do.

We still want to do the best we can to make some changes that cannot be made compatibly without a distinguishing syntactic context, which is why I believe tying those changes to `module` is the best way forward. But those changes should simply mean a few cleanups within a distinguished context of the same overall language.

On top of that, I believe that any explicit opt-in is simply too high a price to pay. People will often not use it in <script> tags, and they will *certainly* not use it in inline HTML attributes like onclick="...". If we are more modest in our predictions of the future, and tie the cleanups to an attractive feature like modules, then people will naturally gravitate towards the cleaner language whenever they want to use modules. But we should not be so idealistic as to ever predict that "everyone will eventually learn to opt in to the new language" simply because we say it's better. That's just too big a bet.

So if we can't predict that everyone will jump with both feet into a new dialect, we have to make sure that the changes we make for the new context are not so big as to cause impedance mismatches between old-style code and new-style code. This way people can generally migrate code back and forth between the contexts without too many surprises. Yes, if they're exploring the bizarre cases of JS, like aliasing of arguments and calling methods as functions, they can still get bit. It won't be perfect. But if, by contrast, we keep expanding the differences by needlessly keeping new features barred from the old context, programmers will be stuck forever having to learn about the many differences between the two dialects, and the spec will be stuck with a growing chasm between two sub-languages of ES.

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.

Dave



More information about the es-discuss mailing list