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

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

# #!/JoePea (5 years 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 (5 years 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 (5 years 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 (5 years 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 (5 years 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ă (5 years 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 (5 years 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 (5 years 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 (5 years ago)

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

# Boris Zbarsky (5 years 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 (5 years 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 (5 years 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 (5 years 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.

# #!/JoePea (5 years ago)

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.

Hello Boris, thanks for your opinion and thoughts!

That's the thing: the only people that may get confused are Ecmascript and JS-Engine experts who know the internals very intimately. I've been making web applications for a long time, and have never had to think about the concept that you've described. I continue to believe that the vast majority of web developers would never get confused, and for those people that could possibly get confused, it would be because they are familiar with browser internals (or hit a browser bug like you describe), and in the first case they actually won't be confused because they are familiar with engine internals, and in the second case browsers need to not create bugs like that.

For all intents and purpose, every developer I've talked to, and every article I've read, treats things like window as the global object. It's as simple as that 99.999999% of the time.

I strongly believe that things should be made intuitive for the vast majority of users, not the very few experts who know enough not to be confused, or the very few people hitting a browser bug that should in all honesty be patched in effort to make things easy for end developers.

All the best,

# Boris Zbarsky (5 years ago)

On 11/16/19 12:52 PM, #!/JoePea wrote:

That's the thing: the only people that may get confused are Ecmascript and JS-Engine experts who know the internals very intimately.

No, it's just people who have functions return values they do not expect.

and for those people that could possibly get confused, it would be because they are familiar with browser internals (or hit a browser bug like you describe)

No, you misunderstand. The bug reports were filed because the behavior was not what people expected. They were duly marked invalid, because the problem was with the expectations, not the behavior...

For all intents and purpose, every developer I've talked to, and every article I've read, treats things like window as the global object.

And this is mostly fine as long as you don't call functions from navigated-away-from windows. Which most people don't, most of the time. And when they do, they get very confused by the results, because reality does not match what they had been told.

But that doesn't mean we should double down on telling them things that don't match reality.

I strongly believe that things should be made intuitive for the vast majority of users

I agree, but in this specific context, what does that mean in terms of concrete proposals you are making?

# #!/JoePea (5 years ago)

They were duly marked invalid, because the problem was with the expectations, not the behavior...

It's a design bug. I know, impossible to fix. I consider such things valid bugs, even if no action can be taken on them.

because reality does not match what they had been told

Reality didn't match what was intuitive. I'd say it is a DX flaw.

Honestly though, I don't know what a fix would be.

I'm not sure I even know what "globalThis" means now. :)

# #!/JoePea (5 years ago)

I should stop asking questions about something that is highly-unlikely to change! I can live with it. :) Thanks anyways for the insights. - Joe

# Boris Zbarsky (5 years ago)

On 11/21/19 5:21 PM, #!/JoePea wrote:

They were duly marked invalid, because the problem was with the expectations, not the behavior...

It's a design bug.

Well, sure, if we're talking about the fact that there is no clear separation in the web platform's exposed objects between "a container that can be navigated" and "the thing currently loaded in that container"; both are represented, kinda weirdly, by "window".

I know, impossible to fix.

Then why was you previous mail saying that browsers should fix it?

I'm not sure I even know what "globalThis" means now. :)

It means "that thing that this would return in global scope". No more, no less.

In practice, in web pages, that thing is a WindowProxy object as defined at html.spec.whatwg.org/multipage/window-object.html#the

# #!/JoePea (5 years ago)

Then why was you previous mail saying that browsers should fix it?

Because I believe they should, but I know they won't. :)

It means "that thing that this would return in global scope". No more,

no less.

And (maybe unfortunately) for many people that amounts to being equivalent to "window". (I know it is wrong, but that's what many people think while not knowing about window proxies).

# Boris Zbarsky (5 years ago)

On 11/22/19 12:44 PM, #!/JoePea wrote:

And (maybe unfortunately) for many people that amounts to being equivalent to "window".

It is equivalent to "window". The thing is, "window" returns a WindowProxy, not a Window...