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]

😢

[KoryNunn]

I'm starting to think globalContext or defaultContext are good descriptions.

And on that:
"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"

The name was ruled out because it implys "give me the global this value"

What..? So... We've ruled out one option because it implys global this, but we've decided on globalThis? WHAT?

I'm really starting to think this is just about pushing something through without regard for quality of result.

[ljharb]

@KoryNunn context-based names are mentioned here: https://github.com/tc39/proposal-global/blob/master/NAMING.md#names-ruled-out-by-this-restriction-6

[KoryNunn]

I don't consider scope and context to be the same thing. The scope of a function holds its identifiers, the context of a function is an object that is in the this identifier.

Im not sure how it would cause confusion since it seems like what is being described is literally the default context.

I'd like to know if my definitions are in line with how other people view these words.

[ljharb]

With that definition, how is globalContext any less confusing than globalThis? It seems like it’d just be picking a more confusing synonym for the same concept (assuming your definition)

[ivanbuncic]

I think because •this• is naturally something you are pointing to and sometimes it is not there where you think it should be.

Context is more abstract, kind a 'hidden' already. Wrapped around the whole shazam.

I think @KoryNunn has the point.

[KoryNunn]

this refers to the object in context in a function. It's something you can change. It's a very specific thing.

Context is a generic term. Context also doesnt add confusion to an already challenging thing to teach.

I used to teach people by implementing the 'magic' and showing them how stuff works. Lately I have to put astrixes on everything because many recent spec additions have an ' oh except for X'

'this is an identifier in a function that points to an object that is the context of that function'

"Oh so what's globalThis?"

'its the global context and doesn't have to be in a function'

"...oh"

[kaizhu256]

from a usability standpoint, globalContext is a god-awful long-name. it eats up precious column-space for those who prescribe to 80/100-column limit style-guides (me included).

globalThis is about the limit of what i'm willing to tolerate in name-length, for something that's so frequently used in integration-level programming.

[TeoTN]

From mobile developer standpoint, globalThis is an awfully long name. I'm programming on mobile devices and want to fit into 60-chars line length. Global is more tolerable for that purpose ;)

[ljharb]

@KoryNunn The word I’d use there instead of context is “receiver”; its context imo is the lexical scope it was defined in - since we have different meanings for it, can you consider that perhaps “context” is confusingly ambiguous?

[aminpaks]

I wish I had the power to cancel this proposal. @ljharb it's never late to be reasonable, you can change this.

[codehag]

@aminpaks this isn't a great way to continue the conversation, and it is very disrespectful to the proposal author. Proposals are a lot of work, and when a proposal in it's third stage, it is something that the committee has agreed upon as being needed in the language in some form. Even if the champion has abandoned it, it is likely to be picked up again. There are a lot of reasons that have little to do with the naming, specifically interoperability between node and the web, that made this proposal necessary.

To move this conversation in a productive direction, I have two suggestions:

Rather than insisting on a name that has already been ruled out (incidentally, in many cases not by @ljharb, but by other committee members):

One might argue for something that would be possible that is beyond what we have already discussed and is already in the document detailing constraints. Incidentally, I would like to point out the following:

• We already have one committee member who will be advocating for Global at our next meeting.
• We will also likely discuss that this is a confusing concept for developers.

Is there another proposal that works for you folks that works within the constraints? This can be treated as a creative exercise and a way forward -- so far it looks like we are looking for something that is global<something>.

On the other hand, one might argue against a constraint in a detailed manner. If you wish to argue against a constraint, but you find that the document is not detailed enough to do so, you can ask and we will give you more information. It looks like the section on context may not be detailed enough, and __global__ might need fleshing out. Unfortunately, we are human and need our family time, and it is holiday time so our resources are limited. Would you folks like one of these to be detailed so you can make an argument against it being a constraint? If so, please pick one for now -- so we can make sure we communicate well about it. Unfortunately, I cannot guarantee that it will be agreed with by the committee, but it may. Even then, it may not be agreed with by the rest of the community, that is also an issue -- we may end up exactly where we are now.

Hopefully this can help us move forward.

[aminpaks]

@codehag Why is it disrespectful? Doesn't matter how much effort you put towards the wrong direction, it doesn't justify it!
Everytime I read this thread I get more frustrated.

[kaizhu256]

@aminpaks, what don't you like about it? i'm ok with its current-form and use it in production with following polyfill.

it simplifies writing unified, globally-aware integration-code that you can copy-paste and run/debug in browser/nodejs/dev-console.

/*jslint browser*/
/*global globalThis*/
(function (globalThis) {
    "use strict";
    var local;
    // init globalThis polyfill
    (function () {
        try {
            globalThis = Function("return this")(); // jslint ignore:line
        } catch (ignore) {}
    }());
    globalThis.globalThis = globalThis;
    // init local object
    local = {};
    local.local = local;
    globalThis.globalLocal = local;
    // init isBrowser env-test
    local.isBrowser = (
        typeof window === "object"
        && window === globalThis
        && typeof window.XMLHttpRequest === "function"
        && window.document
        && typeof window.document.querySelectorAll === "function"
    );
}(this));



// run globally-aware browser integration-code
(function (local) {
    "use strict";
    if (!local.isBrowser) {
        return;
    }
    ...
}(globalThis.globalLocal));



// run globally-aware nodejs integration-code
(function (local) {
    "use strict";
    if (local.isBrowser) {
        return;
    }
    ...
}(globalThis.globalLocal));

[codehag]

@aminpaks Your comment is disrespectful, because it implies that that the champion is not being reasonable, and this has no place in this discussion. Please keep your comments on topic, and keep references to the attributes of specific individuals that you may disagree with to a minimum, as this makes it easy for the thread to get heated and derailed.

To repeat myself: regardless of if a champion abandons the proposal, it is already at stage three, which means that a committee consisting of representatives from various companies and frameworks has agreed that a solution to the problem must be made as the problem is significant enough. This includes representatives from the JS foundation, facebook, google, microsoft, mozilla, etc. It does not mean that the solution in its current form is the right one. Proposals in stage 3 are subject to change. If you find our staging process confusing, please refer to our staging document

[codehag]

@aminpaks -- I should say, Sorry I also lost my temper a bit and had to edit my comment, I also find this thread frustrating. I am hoping we can turn this around.

[hax]

I'm very late for this discussion, just give some thoughts.

First, personally I'm ok with globalThis, and I think it's technically correct if you think it as "what this mean in global scope". Though I'm also like many other choices like Global, GLOBAL, globalObject, etc.

But I have a very big concern about the process of choosing the name. IMHO, the current process of TC39 have big problem in all similar controversial issues. Not only the name issue of this proposal, but also export order issue of decorators proposal, syntax issue of optional-chaining proposal, tail call issue of stc proposal, suggesting explicit semicolon issue of the spec, and the tragic class-fields proposal which is very controversial in almost every aspects but still forward to stage 3 like this proposal.

One of the big problem of current process is, the voices of community can be dismissed too easily, on the other hand, the opinions of a single TC39 delegate can just stop the thing and make all community efforts useless. This is why many community members feel very frustrating.

Use this issue as an example, it's ok to rule out some names as the reasons listed in NAMING.md, but why it's not ok to rule out globalThis as the reasons given by many community members? To be honest, I never understand why the reason of ruling out Global is stronger than the reason of being against globalThis. So the only conclusion I (and many) can get is it's just because the objectors are not in TC39.

This is very very harmful to the relationship of the committee and the community.

---

TC39 use the process of "consensus in the room". It's ok for most issues, but hard to work for the controversial issues I mentioned before. When an issue is controversial, it means there are essential conflict (of use cases, or mental model, or positions, etc.) somewhere. Normally we hope TC39 make tradeoff based on reasonable technical reasons. Unfortunately, because it's an essential conflict, it will be impossible to convince all, so the champions will choose first satisfy the guys in the room. I don't think it's wrong, the guys are in the room because they have big concern about that topic. But the consequence is if people which have very different opinions are happened not in the room, or if there is no TC39 delegates share same opinions as a large part of community (like dislike of globalThis), or even there are some delegates have same opinion but do not have enough motivation and do not want to take the social cost of veto it (like the situation of current class field proposal), such opinions are hard to be treat equally. So the final decision will be more political than technical. (Note, I don't think political is necessarily bad, but if it's political, we must do it in right way.)

I hope the members of TC39 could recognize such process failures, and try to establish some new process to deal with such cases. And because they are process failures, we should not use "already stage 3" as the excuse to refuse the changing (like the suggestions of roll back to stage 1/2).

To me, the most frustrating thing is not specific issue, but the meta issue of TC39 can not fix the process issue. In Oct 11, one of a important TC39 delegate who is the champion of many proposals wrote a letter to me privately:

I agree that it's important that TC39 not add excessive complexity which doesn't serve programmers, and I like the general idea you raise of using a supermajority ballot rather than "does anyone object" to get consensus in certain situations, in particular in order to assure alignment with the community. However, every time I've raised this process suggestion privately with other TC39 delegates, I've gotten significant pushback. So much pushback that I'm afraid to agree with you in public about this.

I hope the author of this letter can forgive me to make it public. But I have to say I'm really frustrating to receive such a mail, if a guy in TC39 like you can not fix it, how can I do anything ?? This is why I never reply this mail.

I'm even more frustrating that after I showed this mail to some other TC39 delegates, some still don't agree there is a process failure. Sigh...

---

God bless JavaScript, and

Happy New Year (let's temporarily forget all such things and enjoy the holidays :-)

[codehag]

@hax thanks for your thoughts, I will try to respond as best I can. These are very serious issues that we have been trying to work on.

The TC39 is in a transition period, we are trying to understand how to do what we do better, in a more transparent way. This will make us make better decisions as well as avoid such situations. Unfortunately this process of change is not without pitfalls and we are bound to make mistakes, so I hope people will be patient with us.

Specifically in relation to this proposal, the NAMING.md file was part of a strategy to make it possible for the community to clearly see the constraints, in order to make it easier for members of the community to engage. @leobalter will be bringing up Global again to the committee, and we will likely discuss issues with this that we hadn't discussed earlier. @ljharb also drafted a comment that addressed the specific failings of this proposal. It is not possible to do things perfectly, but in the future we are hoping to move things in a productive direction.

[smolinari]

I still say, RFCs are a solution that can help improve the process. If feedback is needed for more than one stage, then there can be multiple RFCs. In fact, instead of saying, "the community can chime in at any time they want", which makes gathering the feedback piecemeal at best, the TC39 can specifically ask for feedback - at - the - right - time, allowing for the feedback to be better funneled and collected. The TC39 can be open for other feedback at any time despite the RFC steps too.

this process of change is not without pitfalls and we are bound to make mistakes

I like the humility here. We are all only human. 👍

Scott

[aminpaks]

@ljharb, @codehag I need to apologize for what I said a couple of comments on top. I lost my temper due to frustration (no excuses though) and I shouldn’t have.

I think a couple of comments above things that frustrate me have been mentioned by @hax.

Still I believe we should put way more efforts towards fixing the process. (I don't know how to fix it though.)

Thanks for your hard work.

[dcleao]

My couple of cents.

On the immediate problem at hand

I second @nuragic's comment, in #32 (comment).

For me, either Global or __global__ are far better (and actually great) alternatives. These also avoid the mentioned problems regarding the conflicting, non-universal meanings of the terms context, scope and this as a prefix/suffix (and also of others, such as object, instance, value, reference, namespace and root).

On versioning JavaScript

I think @anurbol's proposal for JavaScript versioning is great — see #32 (comment) and #32 (comment).

Unfortunately, imo, this is one of those aspects of the JavaScript language that TC39 isn't brave enough to tackle. Or, maybe, it is yet to recover from the effort of defining the strict mode... Instead, TC39 rushes into and becomes overwhelmed and overloaded by a multitude of new, nice-to-have, could-definitely-wait-for language features.

Imo, in the long run, this modus operandi effectively jeopardizes said features, by drastically reducing their solution space due to the (real) constraint of backward compatibility. Versioning would preserve the full solution space and would ultimately result in better solutions.

One of the arguments against versioning, mentioned by @ljharb, in #32 (comment), leaves me astonished:

@anurbol there’s a number of reasons that “versions” isn’t feasible - browsers don’t want to maintain multiple simultaneous versions of their javascript engine, for example.

If we weigh pros and cons, for the language, the community, the web — the world, after all — how can browser convenience weigh more? While I see the danger for the creation of many versions, I can also see how this feature could be used sanely, by adequately grouping incompatible features, to serve advancements in an opt-in fashion to the web. There could be, for example, one version per year, aligned with the ECMAScript's yearly release (the old 5, 6, 7, ... numbering could be used). This would also be a great feature for linters and developers, allowing the code to state the ES language level for which it was written for.

Feature testing is great (more like a necessary evil?). Version assurance is better, imo, and the only real enabler of backwards incompatible changes (such as syntax changes). Feature testing would still be necessary for the detection of other web platform features and APIs.

Possibly, language versions could also reach an end-of-life. Would a life-span of 15 years be reasonable? How many pages that use JS and are not modified for the last 10 years still run without errors today (despite our best efforts)? And for 5, and 15 years? Is there a more reasonable, realistic, version of (pun intended) "the web does not break, ever"?
Assuming that the web eventually breaks, how do we develop sites today that will "progressively" and gracefully degrade?!
EOL is optional, though, and would only enable cleaning up the browsers' implementations.

In principle, only a small number of features, across multiple yearly versions, and most of small complexity, would need to be explicitly handled by browsers. Yet, I'm sure there's a tonne of problems in here, but few, if any, should be unsolvable by your great minds :-)

Importance of naming

I second @getify (#32 (comment)) (and others) on the importance of naming. I would dare to define naming as:

Naming is the process of understanding what is it that is being named.

In the absence of a proper name, there's no real understanding of the problem at hand. Deferring the choice of a name is, most of the times, a direct consequence of the lack of understanding of a problem.

Of course, ultimately, several names can match a well understood meaning (semantics), allowing for a final choice to be made later in the process.

Another aspect of the naming problem is extrinsic and deals with how it is perceived by several target audiences.

(Descriptive) Names summarize concepts in the best possible way and they're one of the key (pun intended) things that we humans use to efficiently memorize, predict and understand information.

Names last, for better or worse.

Finding names parallels with finding concepts as part of the design process.

Oh, yes, it is a hard problem to solve. Not one to be underestimated, either in impact, effort or importance.

On the TC39 Process

I also think that lessons can be taken from this proposal's development (and, possibly, from others, as mentioned by @hax, in #32 (comment)) and well (better?) defined points for community involvement could be identified and formalized into the TC39 process. This would help both TC39 and community people to concentrate their efforts and attention at specific times. It would greatly help the community not to miss the wagon passing by. See @smolinari's comments on the topic: #32 (comment), #32 (comment), #32 (comment) and #32 (comment). Also, see @leobalter, in #32 (comment).

On the perceived power of JavaScript engine makers

I'm a bit chocked by the reality so clearly described by @codehag, in #32 (comment):

You might say: "well, this obsession with backwards compatibility is absurd, it is the future of the language that matters". However, if one browser implements something that breaks a number of sites, and their competitor does not -- then there is no incentive to implement the spec as it puts them at a disadvantage in the market. We can be as idealistic as we want, but developers are not the primary users of the web. The people that influence the decisions that browsers make are ultimately users of the web -- creating an experience that undermines them, while another browser does not, doesn't make sense for browser makers from a business perspective. This is not about some high ideal of "we want backwards compatibility just because". This is "If we don't take into consideration backwards compatibility, browsers that implement the spec will be at a disadvantage, giving them no reason to implement the spec in a competitive market." If no one implements the spec, industry collaboration begins to fall apart. This is not good for the web, or for users, or for developers.

I think I understood the described dynamics of the JavaScript engine market. I conclude that engine makers have an undesirable amount of power on the web standards equation; or, the market they live in forces them to act very conservatively, as a way to protect their "business". While I do believe that no engine maker wishes to harm the web, surely, many times, it is not in their best interests to implement a given feature. Legislation is commonly used to regulate markets...

Could/Should engine makers having a fixed seat at TC39 have (more?) obligations as well?

1. To timely perform instrumentation / name clash testing. Rotating across engines.

   This has been one of the major difficulties faced by @ljharb in this proposal, as mentioned in #32 (comment):

   Doing a “study” requires a browser to be willing to volunteer that time, effort, and performance cost - so far, it took me a year and a half to get one browser to agree to do one such test with no more than 4 names. I am very skeptical that this will be possible a second time, but I’d be happy to be proven wrong.

   It is also said by @bmeck, in #32 (comment):

   One of the big things for me personally, is how hard it is to ensure web compatibility for some features. It takes code searches, rolling out custom metrics in browsers, then actually rolling out browsers, and all of that can lead to eventual rollback and starting over. Doing so is intense enough that it is rare to do multiple of these to completion at the same time for a given feature. For anything proposed TC39 will want breakage metrics (before and after deployment to browsers) and that is part of why roughly constraining the names had to be done.

2. To, eventually, implement all standardized features. Possibly, with a deadline...

3. To implement Phase 3 proposals. Rotating across engines.

Surely, some rules could be thought of to bring some balance to this apparently uneven state of affairs.

[ljharb]

@dcleao Thanks for your thoughts! I appreciate your feedback. I wanted to reply to a few points you made on versioning and engines:

how can browser convenience weigh more?

if browsers refuse to ship something, then nobody gets to use it. If browsers were unwilling to ship versions (note, I'm not claiming they absolutely are, but I suspect they would be), then versions would either never land in the spec - or worse, would land, but never be implemented, making them de-facto non-standard. There's not really a feasible way to force private companies to ship changes in their privately owned and managed software products, nor would it universally be considered a good thing to have a world with that kind of coercion.

There's the secondary concern that many browser versions do not implement precisely 100% of a given edition, and no further - for example, no engine fully complied with ES5 until a year or three ago, despite implementing a great many newer features. Experience and industry advice tells me that feature testing is reliable; whereas version testing (or user agent sniffing) are what's inherently unreliable, because (just like browser user agent strings) versions are often deceptive. There's plenty of times, for example, that a browser (that all of us, I'm sure) shipped a feature, claimed it was "done", and then it had bugs - at that point, you'd either have to maintain a complex table of version numbers mapped to feature tables, or, you could directly feature-test and always find out whether it works as you expect or not.

[anurbol]

@dcleao Your comment (all of it) is like a breath of fresh air, thank you.

@ljharb

if browsers refuse to ship

browsers are people behind them and those people are developers as well, with a sense of beauty (regarding the language), I hope.

P.S. Not to make this discussion bloating up further, just added 2 cents.

[ljharb]

I don’t find versions “beautiful”, and i suspect I’m not alone in that given the committee’s and browsers’ historically consistent and strong stance to not ever version the language.

[dcleao]

https://www.reddit.com/r/web/comments/axp3nx/who_owns_web_standards/

[sindelio]

'global' is the ideal name. Since it's being used by Node.js already, I prefer 'globalThis'. 'Global' looks like a class, because the uppercase letter in the beginning is conventioned for classes.
__global__ is interesting, but I'd leave '__' for the JS engine internals.
That's my 2 cents

[srsgores]

The blacklash this proposal is getting is well overdue thanks to this post.

• globalThis sounds and looks like a user-defined variable name
• why this spec caters to or needs to cater to nodejs makes no sense; node should adhere to the es standards and not the other way around

Pretty much every other suggestion is better than globalThis: GLOBAL_THIS, GLOBAL , and even the __global__. Let's get our $ together and change this

[ljharb]

@srsgores it’s not catering to node at all; code on the web breaks with “global”.

Every browser has shipped globalThis, and has also been unwilling to try any other name. No change can be made.

I’m going to lock this issue; please give https://github.com/tc39/proposal-global/blob/master/NAMING.md a thorough read before filing future questions about naming rationales.