a set of names for consideration

[ianstormtaylor]

Hey all.

First, I just want to say thank you to @ljharb for writing up and championing this proposal to get it this far. I think it this entire proposal is a great idea for something to standardize.

I only open this, because I've read through all of the naming discussions and the ad-hoc suggestion flinging that happened over many old issues, and thought that it wasn't really a good approach for the mob to find the best name. (Mobs are good for finding potential names, but not really for presenting good arguments for or against.)

So, I'd like to present a small selection of names, in the hope of preserving the original intent that @ljharb had for this proposal, while also taking into account @rauschma's well-intentioned worry about "this" causing confusion in #31. Please, hear me out! Thank you all.

So...

Non-recommendations

Before talking about naming choices, I just wanted to try and summarize the main choices that had been made previously but are now removed from consideration, so everyone's on the same page, and so we don't end up with mob rule again. (I did my best to try collect the actual reasoning why things were removed from consideration, but sometimes it really wasn't clear, which might have been part of the issue with the process.)

• global — Removed from consideration, unfortunately, because it breaks existing websites (like flickr.com) that rely on global not being defined in browser contexts. This was obviously the top choice.

• window — Removed from consideration (or never was considered) because it breaks existing code that relies on window implying a browser. Also it doesn't make sense for non-window-based environments to define a global variable called "window".

• this — Removed from consideration because this is not available in modules or in strict mode. Also, people have lots of trouble understanding JavaScript's "this" concept, and adding more confusion by using it for more things is the opposite direction people are trying to go. More and more features are being added that remove the need to think about this, and I think that's a good thing. I'd argue that this ever referring to the global namespace was a strange quirk in everyone's mental model.

• top — Removed from consideration because it is already exposed as a global in browser environments where it has similar but different meanings, so it's not an option.

• System.global, Object.global, etc. — Removed from consideration because they didn't want to tie it to one of the existing or future namespaces, because it should be a global variable itself. And in the case of Object because it would mean that any object could access its global variable context which is unintended.

• globalObject — Removed from consideration because it goes against how browser runtimes actually work, because they differentiate between the "global object" and the "global this value", and the committee does not want to incorrectly name it after another concept that is not what it really is.

• globalScope, globalMap, globalExports, globalEnv, etc. — Removed from consideration because they all are named after pre-existing concepts in JavaScript (or in specific platforms like node) that this globals proposal has nothing to do with, and would cause confusing overlap for users.

• globalVars, globalRef, globalValue, etc. — Removed from consideration because they are awkwardly named in a way that userland variables never really would be. Yo would never name a variable thingValue, thingRef or thingVars, you would just call it thing (or things) by itself without the suffix. This is an aesthetic point, but ideally we'd be able to avoid these awkwardnesses if possible.

• globalRoot, topGlobal, rootGlobal, etc. — Removed from consideration because they are also awkwardly named in a way that uses two words that mean the same thing just to avoid a naming conflict. It would be like naming a variable homeHouse or carVehicle. If we absolutely had to resort to names like this they surely wouldn't cause compatibility issues, but it seems like something we should try to avoid if at all possible.

• theGlobal — Removed from consideration because nowhere else (that I know of) does JavaScript include an article in the name of a variable, so it would be very non-standard feeling. I'm sure we can find a less strange way of expressing it. If we really had to resort to this we could reconsider it down the road.

• store, globalStore, etc. — Removed from consideration because the name "store" is already often used in JavaScript (and elsewhere) for implying some sort of persistent storage, and the global namespace is not persistent in any way. Additionally, on the web there are already many types of storage (eg. LocalStorage, SessionStorage, etc.) so this could cause unnecessary confusion for people.

• globalContext — Removed from consideration for now, for a few reasons. The primary one is that although "context" is a less-fraught way to refer to JavaScript's "this" concept, it would still be naming it after a mental model that we are trying to avoid, since it assumes people think in terms of "give me the global this value", which is not common. We'd rather work towards the 99% mental model case of "give me the global namespace". If it was determined that we absolutely had to fallback to a longer, camelcased name like this, this seems like the best choice, because it doesn't have the overt negatives of some of the other global* suggestions. However, "context" is a concept that so up to now has been useful to have in userland, as an empty canvas that can be used by libraries for their own needs—eg. its use in Koa and React. So introducing a new term with it causes overlap, which may or may not cause confusion.

• globalThis — I'm marking this as "removed from consideration" for the purpose of presenting what I hope are better alternatives. But obviously this is the current running name. But, like @rauschma argued, it adds confusion by re-introducing "this" into a new place in JavaScript for people to learn.

So where does that leave us?

Ideal Candidates

I think everyone can agree that global would be the ideal name, if only it had been compatible. So I think it makes sense to look to try to preserve its semantics as much as possible.

As the top set of choices...

1. Global — There was discussion of this, but it was thrown out because the pascal-cased names are supposed to be reserved for constructors and for namespaces. But when you think about the 99% use case for people, the "global reference" is always for namespacing reasons, and it is often referred to as the "global namespace". So to me it seems like an extremely relevant naming choice. This would preserve the greatest level of intent (since it's exactly the same word, just different capitalization) as the original name proposal. I think it may have been discarded too quickly.

2. GLOBAL — This variable surely would be constant, since it refers to the top-level global this/object for the environment, so why not name it as constants are often named? In fact, GLOBAL is already exposed in node as an alias for global, so there is prior art showing that this is a reasonable naming choice. Using it would also preserve the maximum level of intent.

3. __global__ — Although this is "ugly", it is notable that there is convention for it, since __proto__ is already in JavaScript, and people often use the same double underscore convention in their libraries for private values. And it's worth nothing that there is prior-art of other languages like Python using the double underscore for built-ins that need to not conflict with userland, like __init__. If anything, it would make people think twice before doing too much with the global namespace which seems like a desirable outcome to me. (The same way that __proto__ does.)

4. globals — Another idea would be to use the plural form. Environments that have an existing global defined can now treat it as an alias, and other environments get to have an almost-identical-in-intent named variable. The plural form also feels nice when accessing a global property (eg. const { myThing } = globals), since it's very common for people to name objects/namespaces using plurals.

In my opinion, those are the best choices because they preserve the original semantic intent of @ljharb's proposal most directly, while also not resulting in more awkward naming like globalObject, or potentially confusing names like globalThis.

Fallback Candidates

However, if none of them can be proven to be usable for compatibility reasons, I'd also like to present a few fallback alternatives...

1. root — If we don't want GLOBAL or __global__ because they aren't a "standard" lowercase-named variable, then I think "root" is the next best choice. This word is also frequently used to refer to the top-level object or namespace in programming. In fact, root is already exposed as a global alias in node so it has prior art that could make it a good candidate. And since browser environment checking is often done via window or self, it seems less likely to cause compatibility issues, although this would need to be vetted.

2. self — This would be an apt name to choose because it is already implemented in browers and in Web Workers to refer to the global object, so it has prior art that people are used to. The issue with this proposal, and why it isn't higher in the list is that it has the potential to break node compatibility in cases where people are currently using self to check for a browser environment and do non-node things. The counter argument to this worry is that it's okay for node to release a breaking change using semver. There's another worry that "self" is often a term used in other languages (eg. Python, Ruby, etc.) that refers to an "instance" of an object, which is completely counter to the idea of referring to a global singleton, and this could cause unnecessary confusion. But these worries are something the committee and node would need to weigh. It would obviously be nice to be able to re-use and existing name instead of having to invent a new one.

3. common — It preserves the semantic intent of a shared namespace. It is also a very uncommon variable name, so it won't cause confusion with userland code. And it has prior art in that COMMON was used for the same purpose of accessing global variables in Fortran II (and probably other languages that followed as a result).

4. shared — Similar to common, but with less prior art. Using shared would also preserve the semantic intent of "global" referring to a shared namespace.

5. globe — It doesn't necessarily preserve the semantics of the original "global" name, but it does get close to it in spelling to preserve that aspect of it and keep it closer to what people recognize. It's also a very uncommon variable name so there would be no real worries about conflict (either in compatibility or in general usage).

I don't pretend to be able to make the final decision, since it requires a lot more JavaScript ecosystem knowledge than I have. But I'm hoping it can be useful to present the sets of names all at once, taking into account compatibility as well as developer experience reasons for/against each.

Thanks for listening! And thanks again @ljharb for this proposal.

Edit: I have been updating all three of these lists (the non-recommendations, the ideal candidates, and the fallbacks) as others have responded with new suggestions or with additional arguments for or against any existing suggestions, to try to maintain a full picture. Some earlier comments in this thread may be slightly out of date.

[kleinfreund]

Could you please remove the strike-through formatting? It’s really hard to read it like this.

Also, I don’t believe globalThis is "[r]emoved from consideration".

[smolinari]

the main choices that had been made previously, so everyone's on the same page

change to

The main choices that had been made previously, but rejected or unusable, so everyone's on the same page

Then you can take out the strike-throughs. 😃

Scott

[ljharb]

@ianstormtaylor it's a bit late for suggestions, as we've already selected the name globalThis, vetted its web compatibility, and it's already beginning to ship in browsers. In other words, the final decision has effectively been made.

As discussed in #31, it's not introducing a new concept - it's what the concept is already called in the spec, and it accurately reflects what it is. I appreciate the feedback, and I'll give my thoughts on your suggestions below regardless:

• common: it's not common to all realms (think: iframes, window objects, node's vm, and the upcoming Realms API, so i don't think this name accurately reflects its semantics.
• shared: same issue as above.
• top: this is already a global in browsers; it would break sites - not an option.
• root: already a global in node, used on the web for environment detection - not an option.
• globe: this name does not describe what it is, so i'm not sure it'd be good in that respect - and consider non-English speakers. They likely already know the term "global", since they're kind of forced to know it due to the existing terminology, but they may not know what a "globe" is.

[ianstormtaylor]

@ljharb what does "beginning to ship in browsers" mean? Does that mean it's only in nightly versions of them? Or even that is still in a bug tracker to be implemented?

Edit: Looks like it means that it landed on a nightly in Firefox 20 days ago, and it got rolled back in Chrome so it's no longer in the Chrome nightly, and hasn't been moved on yet in any other browser. This seems like there is still time to me.

Re: "not a new concept", that's true. But there are lots of concepts that are in the many specs that don't translate well to developer's mental models or good developer experiences. I think @rauschma made a good argument for this. And if there's any way for us to improve the naming still I think we should take it.

Re: common and shared... that doesn't really make sense as a counter argument to me. The words "global", "common" and "shared" are all used fairly interchangeably in programming conversations (and mental models) right now. So you could apply that same counter argument to why the word "global" doesn't make sense. If people will be confused that "common" doesn't apply across iframes, why would they not be equally confused that "global" doesn't either. These are still the best two of the second set of choices I think.

Re: top and root, I totally agree with you. I figured there might be an issue with top, but I wasn't aware of the root global in node. And I also agree that globe is not ideal, hence why it was the dead last option.

But what did you think of my top-three list above?

[ljharb]

I don't agree that "common" and "shared" are used interchangeably with "global" in JS - "global" has a very specific meaning, as it refers to global variables, and colloquially, the global object - whereas "shared" and "common" are terms I see more often in terms of shared helpers in a library, or common CSS styles in a web application. I totally agree that "global" offers similar issues about "well, it's not really global across realms", but the already-adopted legacy and community usage of that term imo trumps that confusion.

[ianstormtaylor]

Yeah, but no one has an issue with the "global" part of it.

It's the "this" part of it that is the issue. The argument is...

Right now there may be a concept of "the global this reference" in the spec. And that's fine for spec people to call it that. But everywhere else in JavaScript we've been trying to get away from using "this", because it is rife with confusion. So much so that as new JavaScript features have been introduced, they've actively worked to eliminate this usage. So although it may "technically" be called the "global this", we should not name it that for end users to use. It will be confusing.

Not only that, but it will also not match what people want to use it for! The reality is that end users are going to use it as a global namespace for putting shared (or common) references to things that need to be global. That is the 99% use case.

And that's why I've argued above that since global is not available to us, we should either (a) choose from the set of GLOBAL, Global, __global__, or globals, or (b) choose from common or shared which are both extremely close in semantics and have prior art.

Edit: The suggestions in the original comment have been updated over time as I've incorporated feedback from others in this thread. So refer to it instead of any interim list for the current picture.

Otherwise, we're just spec'ing something that is guaranteed to cause more confusion. Why add yet another wart to the spec when there are alternative choices that don't have the same issue?

[kleinfreund]

I don’t agree that common/shared are extremely close in semantics to global. Do you have an example where these names are used for a similar purpose? As @ljharb pointed out:

[…] "shared" and "common" are terms I see more often in terms of shared helpers in a library, or common CSS styles in a web application.

[ljharb]

I don't actually think that most end users will use this feature - and I certainly hope that the years-old best practice of never creating global variables doesn't change as a result of this proposal. If you want a place for shared things, make a module for it :-)

For what it's worth, I did check the web compat of globals, and it wasn't an option, and all-caps names and "double-underscore" names were not palatable to committee members or to myself.

[ianstormtaylor]

For what it's worth, I did check the web compat of globals, and it wasn't an option, and all-caps names and "double-underscore" names were not palatable to committee members or to myself.

Do you remember why globals didn't work? What was the reasoning that "committee members" didn't like all-caps names or double-underscore names? Were they presented with the arguments against introducing another reference to "this" from a new developers point of view? Is any of this documented somewhere I can read?

[ljharb]

@ianstormtaylor because too many websites were using that name already, likely in a way that would break if it was an existing identifier. I assume that it's aesthetics - double underscores are ugly, and only exist on legacy __proto__, and all caps names typically are used for constants, but this global identifier wouldn't be a constant - it'd both be reassignable and mutable.

Typically I'd point you at the meeting notes, but it doesn't seem like detailed notes were taken about name bikeshedding.

[suchipi]

Was Global considered?

[ianstormtaylor]

@suchipi it was, but it was removed because the pascal case is reserved for constructors, namespaces, etc. But honestly, seeing as the "global" is mostly a namespace I don't really see why it wouldn't be a good fit TBH. I'll add it, good point.

[ljharb]

Yes, it was in my original list of possibilities, but the general reaction I got was that it's not a constructor and not quite the same as a namespace like Math, JSON, Reflect, etc.

At some point, I had to create a minimal list of 3-5 possibilities in order to gather web compat data, and I had to make a judgement call to prune the longer list down to that.

[suchipi]

Even with common pascal case conventions aside, I think it's the most palatable remaining choice

[ianstormtaylor]

@ljharb what were the 3–5 choices that you gathered data about? and what was that data?

[suchipi]

@ljharb we all appreciate the work you put into this but I think this is the community telling you you made the wrong judgement call- it's not too late to go back yet.

[ljharb]

@suchipi So you find Global most palatable, I found globalThis most palatable, I'm sure others find other options most palatable - how do you suggest making that choice?

[ljharb]

@ianstormtaylor the data is merely, how many sites are using the global identifier - it was globals, globalObject, globalThis, and global as a control (since we already knew that would be heavily used).

All of them had large enough usage that the web compatibility risk was nonzero, but globalThis had nearly none.

[suchipi]

Let's ask for the opinions of others. I'm not sure exactly who "others" should comprise, but probably at least @rauschma, @getify, and @ianstormtaylor, who have shown interest.

[ljharb]

Gathering feedback is great, and I welcome it! However, given conflicting opinions, are you suggesting that sensible language design should be conducted via polling?

[suchipi]

No; don't put words into my mouth. I don't think that's a catch-all solution, and applied liberally it will only lead to bikeshedding hell. However, I am interested in the insights of those three individuals, because they might provide more information that could help us weigh one name over another.

I think that given our situation, there's no clear reason globalThis should be used over any other name, right? Because it's just the name you found most palatable, just like I have a name I found most palatable. So how do you propose we find the most sensible name?

[ljharb]

The clear reason to use it is that it's the global this value in Scripts, and the spec already refers to it as globalThis.

[suchipi]

While that is clear to you, someone who is impressively familiar with the spec, I highly doubt it will be clear to the average JavaScript user- especially as more usage moves to modules instead of scripts in the future.

[ianstormtaylor]

What I would have suggested is...

1. Being open with your naming choices at the time they were choices, and soliciting proper arguments for and against each from a wide variety of people. Twitter is a good medium to spread the word, but not a good medium to receive opinions in. (This would have surfaced the "this" confusion right away.)

2. Then, you can summarize and take those arguments to the committee, and the committee members can make the decision with all of the information. They can be expected to make good decisions when presented with all of the information, but not if only a single point of view is presented. (This means writing up true pros and cons even for the naming choices you don't personally like.)

3. That's it.

---

But to me, it sounds like what happened was...

1. You chose global, which was super reasonable and great! But it had issues. And in the process of discovering those issues people randomly threw out naming options without actually giving detailed arguments for or against.
2. You chose 3 alternatives that you liked which were sort of taken from suggestions, and sort of guided by what you thought the committee liked, but mostly they were just screened by your opinions and perspective.
3. You researched those 3 options, and had to throw out 1 of them due to compatibility concerns. Then there were only 2 remaining.
4. You presented the remaining 2 as the entire set of choices to the committee. The committee then chose 1 of the 2, and we were left with globalThis.

It doesn't surprise me that this didn't result in a solution that everyone was pleased with, because lots of people were never solicited, and even many of the solutions that were posited weren't really considered. It's not really how good design is achieved, you don't artificially constrain the inputs from the outset.

Finally, the most frustrating thing about all of this, is that there is seemingly zero documentation for any of these decisions. Which works well because then it becomes even easier to throw out suggestions as "tried it, didn't work". Which is extremely frustrating.

[brainTrain]

sounds like it's too late to make a change, but was globalContext considered?

[getify]

Moving my bikeshedding suggestions here:

globalContext globalScope globalSelf

Here's something out of the box:

globals

[ljharb]

@ianstormtaylor i discussed options in #20, as well as with committee members, but yes, ultimately i made a choice (after making every suggested option available to committee members) - that’s how proposal champions are supposed to operate. Part of the issue is that it’s hard to gather this web compat data, so we can’t do it for the whole list. Any choice made would have involved preemptively discarding some alternatives based on our collective intuition - that’s what happened here.

I’ll take responsibility for insufficiently documenting the naming choices, and I’ll update the readme tomorrow to hopefully clarify the history there a bit.

The reality, though, is that no matter how many people are consulted, every decision made will fail to please everybody. It’s certainly unfortunate that people aren’t happy with this choice.

[ljharb]

@getify globals was one of the names (if you read farther up the thread) that i actually gathered web compat data on, and was thus proven to be a nonstarter. A name containing “scope” would also have been summarily rejected since, as I’ve explained, there’s no such thing in JavaScript as a reified score object, including the global scope - while global vars are properties of the global this value, global consts/lets are not.

“Context” isn’t an option that was considered, but to me it means much closer to “scope”, which for the reasons above would be both an incorrect and imo much more confusing name.

[suchipi]

The reality, though, is that no matter how many people are consulted, every decision made will fail to please everybody.

I don't think this is a sufficient argument to choose globalThis over any of the other proposed names that don't have web compat issues. I recognize you are the champion of this proposal, but it seems you are giving artificial weight to your own opinion.

[suchipi]

Also, this is an aside, but it just occurred to me- even though there aren't reified scope objects in JS, properties of the global object are available as free variables in all scopes, so the global object is pretty damn close

[getify]

@ljharb your comments about scopes and context being "wrong" and thus rejected demonstrates your disconnect (harshly labeled "academic pedantry") from the constituents from whom you should be caring about opinons more than your own...

and no i'm not saying I universally represent them (or even well), but since literally my entire job is to interface with people all over the world trying to learn and make sense of JS, I think I have some useful insight.

Every bit of that reasoning and rejection of "scope" (and "scope" related words) is exactly the problem here... that's textbook TC39/browser-dev speak that's entirely out of sync with the general developer. There's like 25 people on the planet, outside of TC39, who would ever care or make sense of all that nuance about global proxy and stuff. Almost every one of them work for a browser. The rest of us think of it (and use it as) "the global scope".

[ianstormtaylor]

@ljharb I would consider your comments in #20 to be an example of exactly how not to solicit feedback for a design problem to arrive the best solution. Pretty much every mistake was made. Here are quotes from you in that thread...

The proper solution here is either to come up with a web-compatible top-level name that has "global" in it ("self" is a terrible name), or to namespace it under a new or existing web-compatible top-level name.

I'm pretty strongly only going to go forward with an identifier that includes the word "global". However, due to web compatibility issues, the only productive suggestions are ones that accompany actual browser usage metrics.

I have a list of candidates, but I’d prefer not to advertise them until browsers have helped me ascertain web compat risk. Thanks for your suggestions, but i doubt they’ll end up being helpful (since we probably already have the good ones on our list).

We will find a word that works. Relax, be patient, settle down - something palatable will end up being feasible. It’ll be ok.

There’s a balance here between forward progress, and not using up browser goodwill. We’re waiting on telemetry from browsers; after which we will, indeed, just pick a name.

@sag1v there’s precedent for __global__ but the aesthetics of that aren’t what I’d call “likely to satisfy the committee”, nor myself.

System.global is far more elegant than __global__ or $$global, though, and a namespace of any kind allows for us to use "global" untainted by legacy characters.

It remains to be seen what will work. Specific suggestions aren't really helpful at this stage, though.

From those quotes, I see...

1. Implying that the most important constraints were pure aesthetics, so it's no wonder that more important concerns of developer experience were left by the way side.
2. Showing evidence of having already eliminated entire design decision paths by fixating on the word "global" without seeing arguments for and against.
3. Changing the goalposts, such that __global__ could be immediately thrown out as "unpalatable" but somehow globalThis could not.
4. Discouraging people from submitting suggestions, and at one point refusing to be open about the current proposals, arguing inputs wouldn't help.

It's no wonder we ended up where we did.

I think TC39 should help champions to not have this be the process for things in the future, because it's not good for JavaScript if this is how new features are designed.

[getify]

Relax, be patient, settle down - something palatable will end up being feasible. It’ll be ok.

That didn't work out.

[getify]

globalThis had nearly none [webcompat issues]

Ironically, that's precisely the signal that should have been a red flag. 25 years of people trying to come up with a name for this thing, and "nearly none" of them ever came up with "globalThis" to describe it. I think I know why.

[pluma]

@getify I read that as "palatable to TC39 and browser implementors", not educators and users.

As for the argument "normal users will almost never use it": doesn't that make the argument "double underscores look ugly" irrelevant?

[aleclarson]

Is this identifier likely to be taught to beginners? If not, I'd say globalThis is less harmful than it's made out to be.

edit: Removed my suggestions, as they have now been addressed in the OP.

I vote for Global, GLOBAL, globalContext, or globalScope.

[getify]

Is this identifier likely to be taught to beginners?

Absolutely. New learners by default interact with the global scope, and especially in the browser via "window", they're naturally curious about the object that sure seems like it represents the global scope. Once whatever this feature keyword is exists, it'll be documented and taught and googled quite frequently.

I'd further more posit that if it wasn't going to be taught and used by the general JS dev masses, then we shouldn't add this feature at all (especially given the naming contentions here). If this feature is only used rarely and/or only used by lib authors, it's better that we just keep it to the hack/workaround of new Function("return this")().

[GreLI]

Global — There was discussion of this, but it was thrown out because the pascal-cased names are supposed to be reserved for constructors and for namespaces. But when you think about the 99% use case for people, the "global reference" is always for namespacing reasons, and it is often referred to as the "global namespace". So to me it seems like an extremely relevant naming choice.

This is highly reasonable. Quite a JS way, unlike many other proposals. Seems almost perfect. I believe it's underestimated.

[bmeck]

First off, I would like to see this feature and it does seem that having a standard name would benefit education.

Comments about all the possible names we could choose can also make this process harder. If people have names, we can discuss them but please limit them to some of the top ideas you have and double check against if they have any glaring problems by using things like REPLs in Node/Browsers/github search/google search/etc. A variety of names have already been investigated by @ljharb and we can choose to disagree to some extent; however, we should remember that everything has trade offs and those trade offs do change on minutia that might seems baffling unless we talk about them. Some of these trade offs are even seemingly arbitrary due to differences in design preferences. We can talk about those things, but we should avoid making claims about people and/or trying to prevent discussion of any party's side.

That said, I am seeing some heated feelings here. Lets try and keep it civil and remain positive about what we can do together. Complaints are informative, but we need to be serious about things and work together rather than encouraging division. The more we move towards statements that discourage the other party(s) the less we will be able to communicate about the topic at hand. I'd like to keep in mind, that we are all human here and trying to work towards a better JS. Text on the internet can be hard to infer the meaning of and negativity can be found in text that did not mean to present itself as negative.

Iterating over all possible names for it is not reasonable especially when there are some names being suggested like globalSmoosh that do not appear to be in jest. Jest on the side of TC39 members can get very harsh feedback as was seen with SmooshGate and TC39 have even discussed communication with the wider community in meetings and talked about formal training for members. This leads to a lot of very direct conversation that can be seen as aggressive and/or dismissive which I feel I see on both sides of this topic. That is likely not the intent on any side, but be aware that we are all here talking and that is a good thing. Encouraging political maneuvering and defamation about a given party is something I'd like to avoid. If you wish to discuss politics or make claims about the nature of a given party I'd prefer that be done elsewhere. At any point, if there is concerns about individuals feel free to bring it up after consulting the CoC.

[styfle]

I would vote for any of the choices containing global from @ianstormtaylor original post.

1. GLOBAL
2. Global
3. __global__

These are all really good and much more palatable than globalThis! The fact that the naming convention is different than a normal variable makes it stand out as being a different beast altogether.

I like __global__ the best because:

• very different naming convention to prevent accidentally use (avoid tooling auto-complete when user types the letter "g")
• there is already some precedent with __proto__ as a magic/unusual variable
• other languages like Python's use underscores for magic variables (__init__ or __file__ or __name__).

But I would be really happy with any of those 3 😄

[gartz]

I know that what I will say will sound weird, since the comunity quite love weird name conventions, but for the time we have the chance to call a name that even the most junior programmer would understand what is it.

globalContext

Simple like that, we know that when we are dealing with objects, this retains the enclosing lexical context, now the global context could simply be called globalContext.

You might feel weird, because we use _ for privates or __var__ for experimental variables, then an asterisc to make a function behave as generator. Yeah I get it, JavaScript can't be that easy, but, why not we go for as experiment to try something that is simple and means what the name suggests, people might start knowing what they're are doing and we might end with better apps and libs.

Please consider to keep it simple.

[ianstormtaylor]

@bmeck thank you for taking the time to respond! I agree with all of your points, and appreciate you explaining more about the process. Do you have opinions about my first set of proposed names?

Specifically, referring to your comment https://github.com/tc39/proposal-global/issues/31#issuecomment-442954464:

... global variables are different from global properties since they are not on the global this nor the global object actually and this is where we get more into the weeds. This proposal is about exposing the intended view of the global namespace of properties not variable inspection.

This is a great point.

And this to me makes it even more clear why I think Global should be truly considered as a choice, since we really are talking about a global namespace—as pascal case is for namespacing in JavaScript. (In addition to the reasons I explained in my first comment.)

(And of course, there's always the fallback of GLOBAL which node already uses as an alias for its existing global object, and which should have less compatibility issues than global.)

Thanks!

---

Everyone else, based on the further suggestions in this thread I've updated the lists in the original comment adding more explanations for why I think certain naming suggestions should be included or excluded from consideration. Thank you to @suchipi for re-suggesting Global!

[getify]

globalRoot

rootGlobal

[getify]

theGlobal

topGlobal

topRoot

[smolinari]

If it can be, Global I'd vote for that option too.

Scott

[nuragic]

globalThis would be the ugliest thing ever seen in JS to date.

Whatever but not camelCase. Whatever but not PascalCase. Whatever but withouth this in it.

Please rename to __global__ (or similar) ffs.

[pladaria]

I'd reconsider self https://github.com/tc39/proposal-global/issues/11#issuecomment-443205942

[rauschma]

@pladaria self breaks the web, so it’s definitely out.

[j-f1]

@pladaria How so? It’s already available on webpages.

[rauschma]

@j-f1 Check the description of the issue (at the beginning of this page), please.