Re: ES6 “modes” and user-friendliness

David Herman dherman at mozilla.com
Tue Jan 17 00:30:36 PST 2012


On Jan 17, 2012, at 12:06 AM, Axel Rauschmayer wrote:

> Ah, that makes sense, the thread you mentioned got me confused.

Understandable -- it was a seriously huge thread.

> Then for language implementors, there are three modes/semantics:
> 
> 1. module => ES6 – some changes break with ES5.strict
> 2. "use strict" => ES5.strict + all ES6 constructs that are backward-compatible
> 3. otherwise => ES3 + all ES6 constructs that are backward-compatible

Right.

> It’s a tiny bit messy, but I can see that for developers, the illusion of a single ES6 is more or less intact. Seems like the best possible solution.

Exactly.

> Given that most people are bound to use modules and given that they are a very convenient “switch”, wouldn’t it be best to introduce as many breaking changes via #1 now (as opposed to later, in ES7 etc.)? Especially removing window from the scope chain.

Mostly yes; in particular, modules get their variable references statically checked. But I no longer believe removing window from the scope chain is doable without blowing the "too many modes" budget.

That said, loaders make it possible to create fresh globals, and I still think we should try to introduce a single <meta> tag that makes it easy to opt the rest of the page in to a user-specified loader. But I'm not holding out hope for this to Save the World. :)

> Mark’s email [1] seems to suggest just two modes (#1 being a superset of #2 = subsuming it), but using module as a switch, distinguishing #1 and #2 might be worth it.

It doesn't work. You can't get static checking with strict mode alone, because of situations like

    with (obj) { (function() { "use strict"; ... })() }

But in practice, strict mode can fade away as a transitional concept from ES5 that, while still spec'ed and implemented, doesn't get used much in practice. Modules carry the torch of ES5-strict and take it even further, and become the actual "mode" that gets used in practice, both because it is a useful feature independent of the language cleanups in carries with it, and because it doesn't require a noisy opt-in pragma.

So the language has 3 modes in the spec, but in practice only 2 that matter.

Dave



More information about the es-discuss mailing list