4 ms·

> An actual `window` global with familiar browser APIs This doesn't seem good?

• ericlewis 6y ago
  it's not. actually I would argue any sort of global state like this should go away.
  • ravenstine 6y ago
    Well, okay, but it's pretty much here to stay and doesn't have that great of a drawback that it's worth breaking any cross-compatible code that currently exists. If there is going to be a global object, then it might as well be the same one used in the browser, which everyone who writes JS is familiar with.
  • kinjba11 6y ago
    I agree with the spirit of what you're saying, but there billions of lines of JavaScript code that can't "just go away". Being able to use e.g. 'window.crypto' without worrying about whether I'm in Node, Deno, some other runtime or a browser is great news for reusing huge amounts of code.
    • cpcallen 6y ago
      I'm in favour of compatibility and against a global named 'window' in a non-browser JS implementation, and I don't understand why the former necessitates the latter. Since window is the global object, why not just refer to crypto? Then you don't care what the global object is named.
      • afiori 6y ago
        It is relevant to this that ecmascript specifies `globalThis` as the global object (the one pointed by this outside of functions in non-strict mode), all js environments have it and simiply globalThis === window || globalThis === global