global breaks flickr.com

[evilpie]

See bug 1325907 . Just the existence of global seems to break flickr.com. This caused by code in the popular moment/moment library.

[Jessidhia]

In the babel slack, I at one point suggested realm, as you have one global object per javascript Realm; but @ljharb thinks it's too obscure if you can't tell it's "the global" without needing this kind of background knowledge.

[ljharb]

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.

[sag1v]

@ljharb Is that an answer to my suggestion regarding root being out of the question? :)

[b-strauss]

how about globalObject?

https://developer.mozilla.org/en-US/docs/Glossary/Global_object

[andyearnshaw]

Having the type in the name, globalObject, just seems too weird and ignoring existing naming conventions. For instance, we don't have thisValue, parseIntFunction, argumentsList, ArrayConstructor, etc.

I liked System.global, but System was thrown out so it seems silly to add a new namespace just for global. How about gIobal? Then we can pretend that's how it was spelled all along :grin:

[b-strauss]

Having the type in the name, globalObject, just seems too weird and ignoring existing naming conventions. For instance, we don't have thisValue, parseIntFunction, argumentsList, ArrayConstructor, etc.

DOMStringList, Float32Array, NodeList, ArrayBuffer

😝

[Jessidhia]

Kind of the problem here seems to be that no name for global will be accepted other than global.

My self-righteousness leans more towards blaming JIRA/flickr though 😡

[ljharb]

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).

[littledan]

@ljharb You might have trouble convincing browsers to ship your new names before getting committee and community feedback on them.

[jswalden]

I assume his intent is to keep the candidates on the down-low until there seems plausible evidence they can be shipped, so we don't have another case where some JS library over-eagerly starts trying to monkeypatch and ends up inadvertently poisoning the well in advance of some implementation actually making the change. That is, I assume feedback will happen at some point -- just very carefully.

[andyearnshaw]

DOMStringList, Float32Array, NodeList, ArrayBuffer

Not to be pedantic, but those are all constructors/interfaces and not actually named based on what they are, else they'd be Float32ArrayConstructor, ArrayBufferConstructor, etc 😉

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 the update, I'm guessing gIobal is totally on the list but I understand if you can neither confirm nor deny 😁

[mgol]

How about GLOBAL or Global? -- Michał Gołębiowski-Owczarek

[ljharb]

@littledan the reflector already has a thread for that, where results will be discussed once i have them.

[michaelficarra]

@mgol globał?

[georgir]

Object.global

[benwiley4000]

"Globalism"

[rbuckton]

@ljharb have you considered using a meta-property like import.global?

[ljharb]

@rbuckton import only works in Modules (altho import() works in scripts).

However, then it wouldn't be polyfillable and also wouldn't be possible to lock it down, which is a requirement for SES use cases.

[epeters3]

Is globe out of the question? 🌏

[benwiley4000]

Perhaps there's a more diplomatic way of putting this, but has any consideration been paid to just pushing this through as-is and warning sites like Flickr and Jira to change their code, since they have plenty of highly paid developers whose job it is to respond to API changes?

All the non-global solutions proposed have sounded bad. Writing code which hinges on the assumption that a word - one as predictably-extant-in-the-future as global - would not exist in the web client - was inadvisable. This shouldn't be everyone's problem. Everyone else sane in the world has been writing code that merely checks if window exists, since there's no foreseeable future where a such-named, globally-accessible object would exist in Node.js without emulating a browser API.

The issue is confusing enough to me that maybe I didn't quite grasp it above, but I don't quite see why a few companies' legacy code should be able to derail a proposal that makes sense to everyone.

[Jessidhia]

IIUC, the problem with Jira is not that it is a website, but that it is a web application that is sold, packaged, to corporations; and the problem is in a version of Jira that is no longer being updated.

[doodadjs]

What about my "application/javascript.2" idea, i.e. having a JS2 for breaking changes ?

[ljharb]

We won’t break the web; no consideration will be given to doing that.

No English word is more important than keeping sites working for human beings, nor will it ever be.

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

[zloirock]

@ljharb this issue was opened already 1.5 years ago. In this and related threads, we have some alternatives. Maybe makes sense to choose something instead of being patient? It's just a variable name.

[ljharb]

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.

[benwiley4000]

@ljharb if you intend to call it "breaking the web" then of course I can't agree with that! 😄

I think your opinion is better than mine. Ultimately it probably is better practice not to overload global with new meaning and to come up with a new platform-independent name instead.

It's just the idea of Jira of all things blocking the progression of web, that gives me trouble sleeping at night. 😉

[rjgotten]

IIUC, the problem with Jira is not that it is a website, but that it is a web application that is sold, packaged, to corporations; and the problem is in a version of Jira that is no longer being updated.

Then it's not a matter of 'breaking the web' but a matter of breaking a poorly written application. Those corporations should consider upgrading or should demand a patch for their paid-for product.

[ljharb]

The web consists of many things, including poorly written applications, and we won’t break users of poorly written applications either.

[Jamesernator]

In this case I think it's fine to change the name of global as it's fairly easy to do and doesn't really matter.

But saying "we won't break users of poorly written applications" seems like a dangerous statement as it seems to suggest that if an application did something crazy like if (Reflect.ownKeys(Array.prototype).length > 32) { doSomething() } and forgot to update it if the number ever changed then the TC39 wouldn't add new Array methods ever in risk of breaking that specific site. Obviously that example probably isn't in use anywhere, but I'm sure there's fragile code that could break on similarly trivial additions to the language (especially new globals via if (typeof someGlobal === 'undefined') { var someGlobal = ... }).

It would be nice if there was a clearer definition of what is sufficiently important not to break given a proposal. e.g. Are 1000 users enough? Single bug reports in Nightly builds of browsers? Internal tools? etc

[deecewan]

we won't break the web

what's the threshold on this? There have got to be a million websites that have used some bad practice that will inevitably be broken by some update in the future, such as modify Array's prototype (smoosh).

Surely there has to be a middle ground between maintaining compat and progress?

[ljharb]

@deecewan "progress" isn't measured by "keeping an arbitrary english word"; see https://github.com/tc39/proposal-global/issues/20#issuecomment-379134247 and earlier comments.

[deecewan]

i meant more broadly than the word that is used, but I take your point. I guess what I'm getting at is that there are going to be people who aren't actively involved in the community/don't see these announcements who will have, at one point or another, written some code that may be broken by a proposal, and those voices won't be heard.

what's the threshold on 'number of people affected'? because it currently seems to be 'your voice matters if it's loud enough'.

If there is a better forum for this question, please direct me there.

[ljharb]

When code is broken in a browser, hopefully someone files a bug report to that browser - that’s generally how the committee learns of the breakage. I’m not sure it’s a matter of a threshold (not that we have concrete criteria anywhere), but more a matter of evaluating any reports on a case by case basis.

[sag1v]

Is _global or _global_ out of the question?

[ljharb]

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

[svdb0]

A few more ideas, which have their own pros and cons:

• that (contrast with this)
• __ (double underscore)
• [Symbol.global] on any object
• Object.global (always accessible as ({}).constructor.global)
• const.global, var.global, default.global, or true.global (meta-property similar to new.target)
• default (no ambiguity with the keyword, I think, though it might be confusing)

[ljharb]

@svdb0 at this point, it needs to be a global variable - it can't be something applicable to any object - double underscores aren't what i'd call "aesthetically pleasing" - a metaproperty or keyword wouldn't be replaceable by secure realm tools like caja, so it has to be an identifier.

[rjgotten]

When code is broken in a browser, hopefully someone files a bug report to that browser - that’s generally how the committee learns of the breakage.

You're expecting average consumers with no technical background to have the foresight to know that a new API recently introduced by their browser vendor broke a website they're using, and they have to file a bug report with said browser?

never happening

 

Or are you expecting developers to file a bug report with a browser? Rather than a third-party library they know is broken? Or rather than fixing their own code and/or devising a work-around for their problem?

Management usually has a pathological aversion to factors outside of their control, which means bug reports towards third-parties are usually the very last resort; especially towards browser vendors as those typically take months to resolve and trickle down into a public release, whereas they need fixes in days or weeks.

Even if browser vendors would have a tighter response-cycle, competent management will still ask for another type of fix other than "wait for the browsers to be patched", as regardless of a new version - the broken version will still be out there for users to run into problems.

So...

(almost) never happening

[ljharb]

@rjgotten it happens all the time; that’s how this issue exists, for example.

If users or libraries can and will fix it, then good! Browsers don’t have to be informed, and the web can continue.

Separately, these bug reports often come in from dev/canary/nightly releases of browsers, so they get caught before it lands in a stable browser and affects more users.

[Licshee]

To me, self sounds like a reasonable name for global object in "JavaScript", since it is already standardized in HTML: https://developer.mozilla.org/en-US/docs/Web/API/Window/self https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/self

And people already using self outside of HTML: https://github.com/sergeche/emmet-sublime/blob/master/emmet/bootstrap.js

The biggest problem so far is -- there are many people still using window even if the code is not necessary running on HTML, and it should be no more if either self or global made into standard.

So I believe the only thing we need to do is making self into the standard.

FAQ

Isn't self a terrible name?

Yes, but web developers already getting used with it, seconded to window, which is a worse choice for general-purposed ECMAScript. And since the standardized self in HTML means basically the same thing, it should not be a problem implementing into browsers.

Does it conflict with other use?

I don't think so. Historical, people tend to use self or that to "snapshot" this in current scope, the point is at any moment the code introduce a new var self, it has nothing to do with other selfs outside current scope, and that's why people use self or that or something else to replace this when they need to pass the current this into a nested function implementation. If we make it a standard global self point to the global object itself, it should not cause problem, since there should be no code expects a global self exists or not, even if in some cases developer(s) already getting used with self being the global object itself.

Why not global?

https://nodejs.org/api/globals.html#globals_global In Node.js, global is a completely different animal, it will cause compatibility problems -- or at least Node.js users still have to use something like self. I can't believe that you still tried to put global into the standard even since Node.js already used it for other purpose. Also, as people mentioned above, some website(s) already used global for other purpose(s).

Wait... Doesn't it mean if we made self into standard, all existing code involving self or global object have to be rewritten?

No.

1. If existing code use variables like global or something, a standardized self has nothing to do with them, and don't require changes to the code.
2. If any existing code already use self for any purpose, the standardized self should simply be overwritten, and cause no problem.
3. If existing code used self for purpose other than an alias for global object and willing to use global object in a future version, just rename existing self or choose another variable name to alias the global object like how others did in case 1.
4. If implementation specified behavior is involved, any name other than self can lead to worse situation since only self has known use to be alias to global object. (check what Node.js have done explained for the previous question)
5. If existing code used the global in Node.js, then it has nothing to do with this to-be self, since they are two completely different being.

BTW, https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/520/ shows 404 for now, what was the result?

[GreLI]

Since global isn't really global, but depends on context, frames, etc, may be should it called realm?

[sffc]

window is a noun. I like using a similar noun, like globe (suggested by epeters3) or universe.

[ljharb]

@sffc "the global" is a noun too; despite originally being an adjective, like it or not it's been nouned (yes, "noun" has been verbed; and yes, so has "verbed") by the JS community.

[hollowdoor]

I don't think 'global' is arbitrary as it matches the usage, and means what everyone's been saying since programming was a thing even in other languages. Maybe that's just my opinion. I don't know. Compat is king as well so relevant semantics could be moot. Though the same argument could be made for code base semantics being arbitrary.

What about calling the top level 'arch', 'prime', or 'main'? I don't know if those could be considered arbitrary, but they certainly have a ring to them. I like 'arch' in particular which is also a noun, and adjective. Arch variables?

A single letter would also be viable like 'g', or 'G', or perhaps 'z' the uncommon letter. 'zoo' would provide some entertainment value, and is an occasionally applicable metaphor. :)

Sorry for butting in this late in the game.

BTW 'self' seems semantically odd to me. Is 'global' supposed to be scoped to the current frame like 'window'? 'universe' like @sffc suggests sounds nifty.

[EthanRutherford]

top seems like it would make sense (as in, the top-level scope)

[dcgudeman]

@ljharb If people like global because it is semantically clear why not take it a step further and just call it globalScope

[ljharb]

@dcgudeman that's not clear; it's the global object/global this value, it's not a scope - the line gets blurry when you're talking about global vars, sure, but it doesn't contain scope information (you can't see const values as properties of that object, for example).

[dcgudeman]

@ljharb That makes sense. So would a name like globalObject or globalThis work? Admittedly seeing the capital 'T' in globalThis makes me cringe, maybe thisGlobal would be easier to digest.

[ljharb]

It remains to be seen what will work.

Specific suggestions aren't really helpful at this stage, though.

[hollowdoor]

What is this stage? @ljharb

You said

We’re waiting on telemetry from browsers

But that was weeks ago. Is that still the current stage? I hope I don't come across as impatient. I'm just interested in the process.