ES6 doesn't need opt-in

Brendan Eich brendan at
Sat Dec 31 18:42:52 PST 2011

From: "David Herman" <dherman at>
> On Dec 31, 2011, at 6:08 PM, Oliver Hunt wrote:
> >> # What about eliminating the window from the scope chain?
> >> 
> >> Short answer: giving up.
> > 
> > I think we can drop the global object from the scope chain in ES.  In the context of the browser we need to come up with a way to trigger it.
> Maybe. I don't think it's as important. You can choose to use no globals whatsoever if you want once we have the stdlib available via standard "@" URL's.

Nit-fun: MRLs -- @ cannot begin a URL ;-). We're supposed to say URI (TBL and others pronounce it like "Yuri"), so maybe MRI. Magnetic Resonance Imaging...

> If we can find a simple way to opt out of the global object that isn't a burden, I'm for it. But I suspect if it's too much work, it's just easier... to not use the global object. :)

Right. But I doubt we'll find a simple enough way to opt out of the global object that's also compatible enough to migrate existing code into. That migration hazard, the first finger of fate when we said we intended to remove the global object as top scope, is huge. Lots of code on the web detects properties of window or |this| at top level while also declaring the same name via an uninitialized 'var'.

> > Someone brought up the typeof semantic change as concern :-/
> I'm not concerned. It's technically doable, in that the change would only be within module code. But I think changing the semantics of typeof in only part of JS is a bad idea anyway. It's not enough win to pay for itself. And I think it's pretty clear we can't change it everywhere without breaking the web.

One counter-argument:

1. We want sane isObject and isNull predicates, ideally using typeof. Lack of them continues to bite people, as the web contains code that wrongly assumes typeof x == "object" => won't throw on null x.

2. We want typeof to improve when/if value types appear, and already IE extends typeof's result set, so people have to be careful not to write exhaustive typeof case analysis code.

3. Therefore, to make JS in the future (down the road and around the bend far enough that we can't see all the way -- and if we get there, the look back won't see bad old typeof null == "object") saner in its typeof semantics, we ought to bend a finger of fate on the runtime incompatibility of typeof null == "null".

I'm not going to die on this hill but I think it's worth a bit more thought, at least till midnight ;-).


More information about the es-discuss mailing list