This one-liner will get you pretty close, and does not require installing anything additional, or running code before the page loads:

Object.keys(window).filter(x => typeof(window[x]) !== 'function' &&
  Object.entries(
    Object.getOwnPropertyDescriptor(window, x)).filter(e =>
      ['value', 'writable', 'enumerable', 'configurable'].includes(e[0]) && e[1]
    ).length === 4)

It filters Object.keys(window) based on three principles:

1. Things that are null or undefined are usually not interesting to look at.
2. Most scripts will define a bunch of event handlers (i.e. functions) but they are also usually not interesting to dump out.
3. Properties on window that are set by the browser itself, are usually defined in a special way, and their property descriptors reflect that. Globals defined with the assignment operator (i.e. window.foo = 'bar') have a specific-looking property descriptor, and we can leverage that. Note, if the script defines properties using Object.defineProperty with a different descriptor, we'll miss them, but this is very rare in practice.

Update 2019

With all of today's Webpacks and Broccolis, and Gulps and Grunts, and TypeScripts and AltScripts, and create-react-apps, etc, this is pretty useless, but if you're just working with plain, old, VanillaJS and you want to make it isomorphic, this is probably your best option:

var global
try {
  global = Function('return this')();
} catch(e) {
  global = window;
}

The Function constructor invocation will work even when using --use_strict in node, as the Function constructor always executes in a global non-strict scope.

If the Function constructor fails, it's because you're in a browser with eval disabled by CSP headers.

Of course, with Deno on the way (the node replacement), they may also disallow the Function constructor, in which case it's back to enumerating objects like global, module, exports, globalThis and window, and then duck-type checking which is the global exhaustively... :-/

Crazy one-line solution (Original):

var global = Function('return this')() || (42, eval)('this');

.

.

.

Works

• in every environment (that I tested)
• in strict mode
• and even in a nested scope

Update 2014-Sept-23

This can now fail if HTTP headers in the latest browsers explicitly forbid eval.

A workaround would be to try / catch the original solution as only browsers are known to run this type of subset of JavaScript.

var global;

try {
  global = Function('return this')() || (42, eval)('this');
} catch(e) {
  global = window;
}

Example:
---

    (function () {

      var global = Function('return this')() || (42, eval)('this');
      console.log(global);

      // es3 context is `global`, es5 is `null`
      (function () {
        "use strict";

        var global = Function('return this')() || (42, eval)('this');
        console.log(global);

      }());

      // es3 and es5 context is 'someNewContext'
      (function () {

        var global = Function('return this')() || (42, eval)('this');
        console.log(global);

      }).call('someNewContext');

    }());

Tested:
---

  * Chrome v12
  * Node.JS v0.4.9
  * Firefox v5
  * MSIE 8

Why:
---

In short: it's some weird quirk. See the comments below (or the post above)


In `strict mode` `this` is never the global, but also in `strict mode` `eval` operates in a separate context in which `this` *is* always the global.

In non-strict mode `this` is the current context. If there is no current context, it assumes the global. An anonymous function has no context and hence in non-strict mode assumes the global.

Sub Rant:

There's a silly misfeature of JavaScript that 99.9% of the time just confuses people called the 'comma operator'.

    var a = 0, b = 1;
    a = 0, 1;          // 1
    (a = 0), 1;        // 1
    a = (0, 1);        // 1
    a = (42, eval);    // eval
    a('this');         // the global object

While in browsers the global scope is the window object, in nodeJS the global scope of a module is the module itself, so when you define a variable in the global scope of your nodeJS module, it will be local to this module.

You can read more about it in the NodeJS documentation where it says:

global

<Object> The global namespace object.

In browsers, the top-level scope is the global scope. That means that in browsers if you're in the global scope var something will define a global variable. In Node.js this is different. The top-level scope is not the global scope; var something inside an Node.js module will be local to that module.

And in your code when you write:

• console.log(this) in an empty js file(module) it will print an empty object {} referring to your empty module.
• console.log(this); inside a self invoking function, this will point to the global nodeJS scope object which contains all NodeJS common properties and methods such as require(), module, exports, console...
• console.log(this) with strict mode inside a self invoking function it will print undefined as a self invoked function doesn't have a default local scope object in Strict mode.

I cannot read the mind of Brendan Eich, but I can take an educated guess as to why the global object exists:

First of all, the design of JavaScript is kept very simple: Records (the place where variable values get stored) and Objects are very similar. Both are basically a collection of key-value pairs. That simplifies the design (e.g. a = 1 works the same way as a.b = 1) and has the side effect that objects can easily be used as records (e.g. with the with statement).

Secondly you might also want to refer to global variables although the variable got shadowed. That can easily be achieved with having a self reference inside the global object / record (window is just a self reference).

Therefore it does make sense that var creates a variable in the global record, which, you can also refer to via window..

Actually that const and let do not create a variable on the global scope is the inconsistency, but with that modularity gets achieved.