Proposal: global.window = global

[isaacs]

One of the biggest and weirdest stumbling blocks I'm seeing as people try to use npm and CommonJS for browser code is the difference in spelling of global vs window.

I'd like to propose that we just go ahead and create a global called window that is a reference to node's global object.

Yes, yes, "window" is a silly name. It was silly in the browser, and it's even sillier outside of it. But it's a fixture in the language, extremely low-risk, and will reduce a lot of friction onboarding browser JavaScript people.

[mscdex]

-1 It seems like a bad idea to let people pollute the global namespace by default like that on the server side, especially if there is a dependency that pulls in such browser-side javascript module and the user is totally unaware that globals are being messed with. IMHO it's better to fix the javascript in question to detect node and set module.exports instead.

[cjihrig]

I'm -1. Seems like encouraging a bad habit.

[Fishrock123]

-1

It's not like this is browser-land where there isn't yet a module system in place.

[chrisdickinson]

extremely low-risk

Adding window stands a chance of breaking code that sniffs that variable for environment hints. I can't say how much code – I know anecdotally past me has definitely done it – but it does worry me a bit.

[tellnes]

-1

The ReferenceError you get saying window is not defined does indirectly also says to the user "you are not in the browser now".

[seishun]

-1

Ugly, potentially breaking and doesn't actually solve anything.

[medikoo]

-1 Terrible idea

[moll]

There are probably more problems with importing code that depends on window than just the existence of window. Like not actually being a Window instance.

Perhaps a simple mention of something like JSDOM is sufficient for people looking to run browser code in IO.js.

[isaacs]

So, this is clearly a bit unpopular so far! Nevertheless, some of the objections are substantive, so I will explain my reasoning.

@mscdex You say "it's better to fix the javascript in question to detect node and set module.exports instead." And I don't disagree. But that is orthogonal to the problem. You can still modify the code to detect node and set module.exports, and there are other ways to detect the browser. But this would make much of that work optional, strictly increasing the utility gained from the corpus of JavaScript to date.

@cjihrig What bad habit it would it be encouraging? People already can set things as globals in node. (Not to mention that every module is a global.)

@Fishrock123 "It's not like this is browser-land where there isn't yet a module system in place." I don't see the relevance.

@chrisdickinson Breaking existing node modules is a good point. I should try to see about investigating public npm packages for that behavior.

@tellnes There are already lots of ways we directly tell users that. See also my response to @chrisdickinson. If this is the primary blocker, it can be quantified and investigated quite easily.

@moll While yes, code that does window.open() will never work in node, there's an awful lot of JavaScript that just uses window as a hook for global.

[jbergstroem]

If this lands in tree it'd probably be around forever. For that reason alone I feel time – and counter-arguments like above – needs to stand between opinion and commits.

[medikoo]

@cjihrig What bad habit it would it be encouraging? People already can set things as globals in node. (Not to mention that every module is a global.)

But they don't do that. CJS format as used in iojs, totally deprecates using globals. It may even be better if there's no global exposed at all (as it's hard to find justifiable use case for it).

Bringing window in, will just open pandora's box of issues, for those not familiar with iojs. Those familiar will never try to use window (global either), but those who are not, will expect window to implement tens of things they used to have in browser.

iojs is different world, and it should not pretend it isn't, it'll be just confusing. It's much better if those not educated crash at first step.

[yosuke-furukawa]

I guess ES6 module is the true key for removing friction for browser and server.

If io.js team will support ES6 module, I am -1 on this. we had better to choose more suitable way. And io.js should not add the workaround like global.window.

If io.js team will not support it, I am +1 on this. global.window will save Many JavaScript developers that would like to create libraries works on browser and server.

[Globegitter]

I am with @yosuke-furukawa here. The differences io.js and browser coding should be as minimal as possible and I think supporting ES6 modules should be the aim and would be preferred, but if that is not planned, 👍 for this proposal.

[drkibitz]

-1 on global.window,
but I would like to propose global.self = global
https://developer.mozilla.org/en-US/docs/Web/API/Window/self

It's a very modest proposal as self still represents a WindowProxy without postMessage, but just thought I would throw it out there.

[mathiasbynens]

It's a very modest proposal as self still represents a WindowProxy without postMessage

@drkibitz That doesn’t make sense. In browsers, self === window and self.postMessage === window.postMessage.