Naming suggestion: `esGlobal`

[manhinli]

I know this is late with engines starting to implement the current proposal, but has anyone considered esGlobal?

[ljharb]

That's certainly a new suggestion, thank you :-)

In general, the name "ecmascript" and its abbreviation "ES" were chosen to be intentionally undesirable; I get the impression that there's little appetite to enshrine it in the observable language itself. See the note here which cites a source here.

This certainly isn't listed as a constraint in the naming document; however, my instinct is that it would become one if this name were suggested to the committee.

[manhinli]

In general, the name "ecmascript" and its abbreviation "ES" were chosen to be intentionally undesirable

I won't go against the knowledge of people who are in the committee, but my understanding of it as a compromise name isn't of it being "intentionally" bad.

It may pain some to keep hearing it everywhere but "ES" is very commonly used nowadays as a consequence of the whole ecosystem and greater public engagement with the standards process. Yes, the pronunciation of "ECMA" does sound like a skin condition which I am very familiar with, but I think people are mature enough to not let a name get in the way of an appropriate solution or terminology, especially if the global proposal name "is not something JavaScript developers should be seeing every day - in fact it should be used rarely, if at all."

For example, people commonly refer to "ES modules" because there are other module systems and this particular one is the "standard". This connotation of a "reference" object can be seen in the previous suggestion about using standard and the use of the the article in theGlobal; in a similar vein, es in esGlobal would refer to "the definitive global as prescribed by the standard" and no other thing.

For other additional pros: esGlobal would be 2 characters shorter than the current proposal and avoid this which I've observed to be somewhat contentious in some groups. :)

[mgol]

If the only argument against esGlobal was to not enshrine a connection to the ECMAScript name in JS built-ins then jsGlobal would work, wouldn't it?

[manhinli]

I was thinking that esGlobal would have fewer issues than jsGlobal (naming, usage on web) but I'd be happy with a jsGlobal if that ends up being preferred.

[manhinli]

Here are a few other suggestions I've thought of as well:

• mainGlobal
• defaultGlobal
• runtimeGlobal

[ljharb]

“main” implies there’s more than one; “default” implies you can change it, “runtime” implies there’s a non-runtime global; “jsGlobal” would work better than “esGlobal”, but it points out to me that they both imply that there’s also a non-js/non-es global (think wasm).

[manhinli]

If not js or es, how about hostGlobal, where "host" refers to the "host(ing) compartment or environment"?

[ljharb]

Also not a bad suggestion! I worry that that implies that there's a different non-host global, though (like, a host one as well as a language one), since "host" usually describes the engine.

[manhinli]

I feel that it's a little bit of both:

• the host provides the implementation of the language,
• hosts/engines in practice commonly provide other things available through global/window (allowed for in the language, but such properties are not prescribed in it)

And "host" itself doesn't have to specifically refer to the engine - it can just be the abstract container around the module for example (though I agree that the terminology is commonly associated with the engine.)

[manhinli]

Here's one more suggestion: nativeGlobal

I also did a search and funnily enough it appears as a class in Rhino (albeit capitalised) and refers to the very thing we're discussing, so I would count this as prior art in favour of this?

[kaizhu256]

i like jsGlobal as its shorter than globalThis, and [subjectively] more relatable to js-devs. and wasm is ultimately meant to support js-workflows, at least for forseeable future.

hostGlobal and nativeGlobal are both equal to or longer than globalThis,

[manhinli]

Another suggestion: globalEntity.

I've put up my list of suggestions and notes that I kept on this matter on Google Drive, including ones I personally rejected and didn't post here, which might be of use to people that might want to follow the themes I've looked into. This will be updated as I go.

[hax]

What about globalThing ? 😆

[ethanresnick]

👍 to jsGlobal. As for the "objection" that it implies that there's also a non-js global: isn't there? Namely, the distinct "global object" that browser vendors cite as the reason not to use globalObject.

I think the pedagogical objections to globalThis (i.e.this !== globalThis in a module) are really important.

[ljharb]

@ethanresnick technically that is also a JS object; but also there's only one that's reachable by user code.

[ethanresnick]

technically that is also a JS object; but also there's only one that's reachable by user code.

You're saying the Window/browser global object is a JS object, but that it's not reachable from user code, right?

[ljharb]

@ethanresnick correct; the "global object" and the "global this" are both defined in the JS spec, and the engine can choose to obscure the "global object" with a different "global this" value, or it can expose the "global object" directly. I suppose it would be possible to provide both, but I doubt any implementor would make that choice.

[kaizhu256]

as a small pro for globalThis over jsGlobal, it has nice symmetry with globalData, which i've begun naming for integration-level app-data/app-states.

(function (globalThis) {
    // initialize app-specific globalData
    globalThis.globalData = {};
}(this));

...
globalData.mvcTodoList.forEach(function (element) {
    ...
});

[ljharb]

Thanks for the suggestions!

I'm going to close this for now; the committee doesn't seem interested in this alternative.