Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

# #!/JoePea (a month ago)

I know it may be too late for this, but I imagine globalThis can bring confusion to beginners, especially ESL beginners.

Things like globalObject, systemGlobal, or globalEntity would've been more intuitive; they make sense in plain English.

Well anyways, have a good weekend!

# Jordan Harband (a month ago)

This question is more appropriate for the proposal repo, in which a very lengthy naming document will hopefully answer all of your questions: tc39/proposal-global/blob/master/NAMING.md

Please address all further comments or replies on this topic to the proposal repo.

# Isiah Meadows (a month ago)

If you look in the proposal's repo, they explain the rationale behind the identifier: tc39/proposal-global

Here's a short summary: globalThis is the same value you get from evaluating this in the global scope of a sloppy mode script. This is subtly different than a "global object", which JS has no concept of. There's other nuances involved, too.

Concretely, for one example, globalObject was explicitly rejected because in HTML, the global this is a proxy of window, not the window object itself. The window proxy delegates all operations to the current global window, as you might expect. But here's where things get interesting: during navigation, the window changes, yet the global this does not, so if you define a property, capture the global this, and navigate, the property you just defined will disappear, but the global this you captured still has the same identity as the new reference.

This file in particular explains the naming side of it in detail: tc39/proposal-global/blob/master/NAMING.md It covers the other suggested names here indirectly.

And do keep in mind much of TC39's members are non-native speakers themselves, including one of the proposal's biggest champions/fans, Matthias. So it's not like that concern goes unnoticed - if anything, it gets accounted for without them even thinking about it. It might also explain why it's array.entries(), map.entries(), and similar when the more proper English name would've been array.pairs(), map.pairs(), and so on: entries are really what values from value[Symbol.iterator]() represent, and non-native speakers sometimes misuse "entries" as if it were synonymous with "pairs". Contrast this with Underscore's _.pairs, named by a native English speaker back in 2012, long before ES6 was a thing, and it stood as precedent for having coll.entries() for various collections.

# #!/JoePea (16 days ago)

but the global this you captured still has the same identity as the new reference.

Interesting, I never knew that. Do you have a code sample to show how to detect or prove that?

# Boris Zbarsky (15 days ago)

On 10/4/19 2:39 PM, #!/JoePea wrote:

but the global this you captured still has the same identity as the new reference.

Interesting, I never knew that. Do you have a code sample to show how to detect or prove that?

Sure. The following code logs "true, 5, 5, 5, 5, true, undefined, undefined, undefined, 5" in Firefox, Chrome, and Safari, which shows both the identity staying the same and the property disappearing from the WindowProxy, as well as showing the difference between the WindowProxy and the Window (the bareword lookup finds the var on the global, which is the Window, while self.something goes through the WindowProxy, which now points to the new Window):

<!DOCTYPE html> <body> <script> var state = "first-load"; var cachedThis; var cachedValueGetter; var cachedBarewordGetter; function loadHappened(iframe) { var win = iframe.contentWindow;

   if (state == "first-load") {
     cachedThis = win.getGlobalThis();
     cachedValueGetter = win.getPropertyValue;
     cachedBarewordGetter = win.getBareword;
     console.log(win == cachedThis);
     console.log(win.something);
     console.log(cachedThis.something);
     console.log(cachedValueGetter());
     console.log(cachedBarewordGetter());
     state = "second-load";
     iframe.srcdoc = iframe.srcdoc.replace("var something = 5;", "");
     return;
   }

   console.log(frames[0] == cachedThis);
   console.log(frames[0].something);
   console.log(cachedThis.something);
   console.log(cachedValueGetter());
   console.log(cachedBarewordGetter());
 }

</script> <iframe srcdoc=" <script> var self = this; var something = 5; function getGlobalThis() { return self; } function getPropertyValue() { return self.something; } function getBareword() { return something; } </script>" onload="loadHappened(this)"></iframe> </body>

# Raul-Sebastian Mihăilă (14 days ago)

Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed.

# Boris Zbarsky (13 days ago)

On 10/6/19 2:58 PM, Raul-Sebastian Mihăilă wrote:

Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed.

There is a proposal for addressing that. Firefox has been shipping it in Nightly for a while, but we have seen zero interest from any other browsers for addressing that issue...

See tc39/ecma262#688 and following comments for the details of the proposal.

# #!/JoePea (13 days ago)

I never knew any of all that stuff you have all mentioned, and as an end user, I don't think I would ever need to know. To me, I use window as a global object, and it has never been more than that.

I've never written any sort of code that can prove or verify any of what you all are talking about. Mind showing code samples?

If a sample of code isn't possible, or if to the end user there's really just some single global object as far as their code is concerned, then "global object" is in fact a good name. That's why I'd like to see how what has been said actually manifests itself in end-user code.

# #!/JoePea (13 days ago)

Ah, this thread got forked from the other one, which has a code sample. Taking a look at that...

# Boris Zbarsky (13 days ago)

On 10/7/19 1:29 AM, #!/JoePea wrote:

I've never written any sort of code that can prove or verify any of what you all are talking about. Mind showing code samples?

Did you not see esdiscuss/2019-October/053033 ?

# #!/JoePea (13 days ago)

Who's going to write code like that anyways?

Everyone's moving to ES modules, where this for accessing the global is just undefined. It's highly unlikely that any concept other than "global object" will ever be conceived by the vast majority of users, especially future users.

# #!/JoePea (13 days ago)

I didn't see it. For some reason my gmail thread split into two separate threads, and I read one before the other.

# Boris Zbarsky (12 days ago)

On 10/7/19 1:56 PM, #!/JoePea wrote:

Who's going to write code like that anyways?

In the general form of "function from a navigated-away-from document runs because it's called by some script from outside the document", I've seen this come up a number of times in web browser bug reports.

Everyone's moving to ES modules, where this for accessing the global is just undefined.

It's not just "this". The same thing applies to "window", "self", etc, etc. There is no way to actually get your hands on the global object explicitly in a DOM Window scope: you always get the WindowProxy instead.

It's highly unlikely that any concept other than "global object" will ever be conceived by the vast majority of users, especially future users.

Well, the thing that globalThis returns is NOT the global object, and telling people that it is will just confuse them when it behaves in a way they don't expect.