Please use a name without `this` in it

[rauschma]

I know it’s late, but please reconsider the name globalThis:

• this has always been a topic that mystifies programmers, especially those who are new to JavaScript. There is a constant stream of blog posts about it.
• ES6 made things simpler, because you could tell people to prefer arrow functions and only use this inside method definitions.
• In modern JS (=modules), you don’t really encounter “global this”, so globalThis doesn’t even refer to an existing concept.

The name globalThis would make this more complicated again.

One possibility (but I’m OK with anything that doesn’t have this in it):

• Use the name globalObject – that’s what it’s always been called.
• The readme mentions that global* is not really the global object, but I don’t find it helpful to be pedantic in this case.

[j-f1]

currentRealm @STRML?

[selipso]

I've been programming in JS for 5 years and started using JS frameworks in year 2 because of this, global, and window. It's already too late to solve those problems at the language-level but frameworks abstract it away really well and I've never looked back at unscoped this and global except for the occasional polyfill that needed a tie-in between global and window. With all due respect, I think the energy-to-impact ratio of this discussion is already too high.

The web, to me, as an intermediate developer and JavaScript tutor, has always stood for interoperability and cross-device compatibility. Any name that accomplishes those goals with agreement from browsers and maybe saves a few lines of polyfill code, I would be fine with. Unlike when JavaScript first appeared, the web now has another competitor: native code. The more we as a community can focus on issues related to interoperability and cross-device compatibility, the more we can move towards allowing JavaScript to be used with richer APIs that resemble modern native functionality.

On a lighter note, since naming is hard and it's a variable that isn't supposed to be accessed anyways, why not make that obvious to a beginning programmer? My favorite so far has been rootRealm but the message would be just as well communicated with something like shadowRealm or godObject or globalGod or just browser or browserContext for the spiritually sensitive.

[felipenmoura]

IMHO, if I understand it right, this this is actually an instance for the current global scope, which you can use to store data "in purpose". For example:

const foo = 123; // this will NOT appear in globalThis
globalThis.foo = 123; // this one, will

Is this the goal for it? If so, I too dislike the "globalThis" name and would go for something more explicit and less usable :p What about one of these:

• currentGlobalScope
• globalInstance
• self.instance

The self.instance suggestion could also be an instance property in a different global object, like navigator and/or process ... this would allow it to be available in workers, node, browsers, etc.

Or am I not understand its objective correctly?

[TeoTN]

I'd say... are you insane? Have you seen this kind of rubbish naming being praised in any other programming languages? What's next? globalWakaWaka because "we've already named it that way in our code so stick to it because of reasons"? We're just creating a brand new source of confusion and JS rejection, sort of #defining WIN32_CLEAN_AND_LEAN in terms of naming. What's wrong with using shared, root or common that would make it look like a feature, not a bug? Do we need a completely new set of web browsers to have a clean and legible programming language?

[AshleyScirra]

@TeoTN - I think your attitude is unacceptable. This discussion should not involve calling people "insane". I would point out the TC39 code of conduct which emphasises being respectful, friendly, patient and considerate, and identifies personal insults as a potential harassment and exclusionary behavior.

[pladaria]

Can self be reconsidered?

https://github.com/tc39/proposal-global/issues/11#issuecomment-443205942

[TeoTN]

@AshleyScirra it doesn't address any of concerns presented neither by me nor by anyone else here. It wasn't also directed to anyone just drawing attention. I'd say though it's against code of conduct that multiple people voices here are simply ignored, voices that are coming from quite significant personas for the JS community for the sake of "we have already written that in this way so deal with it".

[gesa]

Thanks for everyone's input here. We (representing @tc39/code-of-conduct-committee) are going to lock this issue as it is no longer productive. For more context on why a long list of potential names didn't work, check out #32.

@TeoTN: As mentioned by @AshleyScirra, the comment you made above is in violation of the TC39 Code of Conduct. Whether used as a direct attack or for the purpose of gaining attention, the language used was highly aggressive, with no intention to be productive. This form of communication is unacceptable.

[ljharb]

First, I want to thank all of you that have taken the time to provide your thoughts - @rauschma, @joelnet, @getify, @mchandleraz, @KoryNunn, @smolinari, @feross, @kleinfreund, @ianstormtaylor, @suchipi, @pleerock, @AshleyScirra, @fkling, @STRML, @j-f1, @selipso, @felipenmoura, @TeoTN, @pladaria, and many others. I really appreciate your feedback, and I know that you're all coming from a place of caring about the JS language. I've tried to take some time away from this thread to collect my thoughts, and I want to reiterate that I appreciate any and all feedback.

My tone has at times come off as dismissive and overly harsh, and I apologize for that. Sometimes I respond when tired, or stressed, or when emotional, and I'll try to get better at taking a pause so that I can respond calmly, respectfully, and with an open mind.

We humans on TC39 take community feedback very seriously - and at the November meeting, we had an emergency break from our agenda to take the time to address this proposal's recent feedback. I asked another committee member (who was concerned about ensuring we listen to the community, and particularly prominent educators) to conduct the discussion, so as to ensure that any of my personal bias was minimized. The first browser that will be shipping this proposal, Chrome, shipped recently (after the meeting). The Chrome team assured the committee that they would have no problem removing the feature if the committee decided to make a change, but that pulling it at such a late hour would be a hardship. The purpose of stage 3 proposals is to gather feedback - from both users and implementations - and this thread’s feedback is part of that.

I do want to collect all the name suggestions in one place, and others have asked for this as well. I’ve started by detailing the suggestions and some of the constraints here. Please feel free to file new issues if you have additional names to suggest, or if you think the document can be clarified.

No decision will please everyone, but I truly hope that detailing the constraints (something I clearly failed to do much earlier in the lifecycle of this proposal) will help you understand the decision-making space available, and that we can all move forward with everyone on the same page.

I would like to see our community go in a direction that is positive, where people’s opinions are respected and their voices are heard. While there were personal attacks against myself, there was also a lot of hostility in general, and that hostility makes it more difficult to achieve that positive outcome. We’ve been working hard at TC39 to improve our communication and have developed a Code of Conduct that we will hold ourselves to, and would like to ask our community members to do the same.