MDN's documentation

[jwalton]

From NAMING.md:

This also means that the name can't meaningfully be "realm"-related, nor can it imply that it's some kind of "ultimate top thing".

From MDN's documenation:

The global globalThis property returns the top level global object.

(Emphasis mine, in both cases.)

But, I mean... can you blame them? How else would you describe this? globalThis is consistent with naming in the spec... but how many JS developers have bothered to read the spec?

[ljharb]

Who’s “them”? MDN is a wiki; anyone can edit it.

I’ll leave this open til I’ve had time to go in and correct it.

[jwalton]

Apparently "them" is whoever last edited the wiki. :)

[ljharb]

I guess I’m confused about something - what are your intentions with filing this issue? Although i’m happy to correct MDN, you’re certainly capable of doing it yourself. I’d love to understand why this isn’t an implicit complaint about things already addressed in the naming document - can you help me out?

[jwalton]

1) Despite using MDN almost daily for years, I embarrassingly have never realized it was a wiki.

2) "How else would you describe this?" was a genuine question. While I could edit it, I don't know how I would make it clearer. So, my intent was to ask this question.

this at the "top level" (i.e. outside of any function) of a .js file references the same object (this === globalThis), so in that sense it is exactly the "top level global" object. Or is that not correct?

Or maybe this was addressed in NAMING.md and I just didn't understand it, in which case I apologize for wasting your time, but I've gone back and re-read it a few times and I'm not getting it. And, the more I read it, the more lost I'm getting. I feel like I'm missing something here:

Must be a global identifier, so that it can be "deniable" per compartment - meaning, that two conceptual "compartments" in the same realm must be able to be provided two different objects for the global. This means it can't be stored on any object that's accessible via syntax (ie, undeniable) - so it can't be a property on Object, or Function, or Error, etc. This also means that the name can't meaningfully be "realm"-related, nor can it imply that it's some kind of "ultimate top thing".

So, "realm" is a realm as defined in S8.2? And "compartment" isn't in the spec... so... we're talking about a compartment?

But isn't the global object associated with the realm? Like, there's the "global object" from S18, and S8.2 says there's a global object associated with the realm. And HTML 5.3 S7.1.3.5 states: "There is always a 1:1:1 mapping between JavaScript realms, global objects, and environment settings objects", and defines a "global object" as "a JavaScript object that is the [[GlobalObject]] field of a JavaScript realm".

Is this at the "top level" not the S18 "global object"? So why can't the name be realm related? And, even if we want more than one global object in a realm, why does that preclude it from being a property of Object?

But then I read the bit about WindowProxy in the README, which I skipped before because I'm more of a back end guy to be honest, and I get to this bit:

Therefore, globalThis is not the global object.

And then I go back to the top of the README, where it says:

It is difficult to write portable ECMAScript code which accesses the global object. On the web, it is accessible as window or self or this.

(Emphasis mine)

So globalThis is window, which is the global object... but globalThis is not the global object. And now I'm just totally lost. So, in NAMING.md you said globalThis was providing access to the object 'known in the spec as “the global this value”,' so I figured I'd open up ECMAScript 9.0 and search for "global this value", but despite the fact that you quoted it, it doesn't show up in the spec. "global this" appears in "InitializeHostDefinedRealm()", but now I'm back to an object that's 1:1 with a realm, so I assume that "global this" isn't the "global this" you're talking about?

[j-f1]

My reading is that in 99+% of cases, globalThis is functionally equivalent to the global object, but in certain cases it behaves differently.

[ljharb]

By “compartment” I’m referring to a sub-scope in a realm (not the thing you linked); ill try to find a proper definition of it to link from the document.

In every case in the browser, it’s a Proxy around the global object, which is revoked if you navigate to another page. This section in the readme hopefully helps explain this a bit.

It’s quoted not necessarily because it appears verbatim, but because that’s the concept it represents. https://tc39.github.io/ecma262/#sec-setrealmglobalobject and https://tc39.github.io/ecma262/#sec-newglobalenvironment have a thisValue argument; global environment records have a globalThisValue internal slot.

[jwalton]

Ah, for some reason when I searched the spec I didn't findGlobalThisValue.

In every case in the browser, it’s a Proxy around the global object, which is revoked if you navigate to another page. This section in the readme hopefully helps explain this a bit.

I read it, but I didn't really grok what it was trying to say. Literally right before you replied I was poking around in codepen, and I was like "globalThis hasn't changed, foo has disappeared from frames[0], but foo has disappeared from globalThis too. So is it just a proxy for the global object?" Putting "It's a proxy around the global object" in that section would probably have been helpful to me. :)

So, in a browser, globalThis is a proxy for the "top level global" object, in other environments it may be a direct reference to the global object? Is that correct?

[ljharb]

Correct (it may also, in other environments, be whatever object the host wishes)

[jwalton]

I still feel like I have to be missing part of this; why is topGlobal a poor name choice, then, if it is in fact the "top level global"?

[ljharb]

It's the top level global in the realm, i suppose, but there's no guarantee that the current realm is the "top" - ie, it might be contained within another realm.

[jwalton]

But is there an expectation that topGlobal would somehow be a gateway to another realm? When you reference window inside an iframe, you don't expect it to give you back the containing window, for example - you're expecting the iframe.

But if it really is the top level global in the realm, why are realm related names disallowed? Why not realmGlobalObject? What is a sub-scope, and why should I worry about one when useglobalThis?

[jwalton]

(Or, to be more specific, why is realmGlobalObject a bad name?)

[ljharb]

The "compartments" constraint means that there may be multiple conceptual "regions" or "compartments" or "scopes", in which they are in the same realm (they share the same Error, Array, etc) but do not have access to the same global. In this scenario, a realm-based name would imply that compartmentOneGlobal === compartmentTwoGlobal would be true, but in reality it would be false.

[jwalton]

Can you give me a real life example of this?

[ljharb]

cc @erights who can explain it better than i can.

[ljharb]

Closing, as I've updated MDN. Happy to continue discussion here, as well.

[jwalton]

Thanks for patiently explaining it. :)

[erights]

@ljharb It is a long thread. Is there a specific question I can help answer or clarify?

[ljharb]

@erights specifically if you could talk more about the concept of "compartments" - or even better, provide an explanatory link that the term can point to from places it's mentioned in this repo :-)