All JavaScript code executes in some environment, most commonly in a browser. The code that executes must execute in some "root" scope referred to as the global context or global scope (think of it as the main container). In your browser, this "root" scope is the window object (unique window object per tab, page, or iframe).

That is why when in the example a variable gets declared in the global scope var carName = "Volvo"; you can access this variable on the window object window.carName, because in the browser the 'window' object the global object.

When you execute JavaScript code using Node.js for example the global object is very aptly named global and in that environment if you declare var carName = "Volvo"; you can also access the variable using global.carName (this is only true on the Node.js REPL; var declarations in files do not attach to the global object).

To elaborate:

var myObject = { };
myObject.myVariable = 1;
console.log(myObject.myVariable); // Logs 1

myVariable is created on myObject, and this is done explicitly.

var myVariable = 1; // Behind the scenes this declaration is doing window.myVariable = 1;
console.log(window.myVariable); // Logs 1

myVariable is implicitly created on the window object which in the context of a browser is the global object.

For maybe a better explanation, I strongly recommend this book series You Don't Know JS Yet (book series) - 2nd Edition, specifically for this question You Don't Know JS Yet - Scope & Closures - 2nd Edition

Yes, there are a couple of differences, though in practical terms they're not usually big ones (except for your #2 — a = 0; — which A)  I strongly recommend not doing, and B) is an error in strict mode).

There's a fourth way, and as of ES2015 (ES6) there's two more. I've added the fourth way at the end, but inserted the ES2015 ways after #1 (you'll see why), so we have:

Copyvar a = 0;                             // 1
let a = 0;                             // 1.1 (new with ES2015)
const a = 0;                           // 1.2 (new with ES2015)
a = 0;                                 // 2
window.a = 0; /*or*/ globalThis.a = 0; // 3
this.a = 0;                            // 4

Those statements explained

1. var a = 0;

This creates a global variable which is also a property of the global object, which we access as window on browsers (or via the globalThis global added in ES2020, or via this at global scope). Unlike some other properties, the property cannot be removed via delete.

In specification terms, it creates an identifier binding on the Object Environment Record for the global environment. That makes it a property of the global object because the global object is where identifier bindings for the global environment's Object Environment Record are held. This is why the property is non-deletable: It's not just a simple property, it's an identifier binding, and identifiers can't be removed.

The binding (variable) is defined before the first line of code runs (see "When var happens" below).

The property this creates is enumerable (except on the very obsolete IE8 and earlier).

1.1 let a = 0;

This creates a global variable which is not a property of the global object. This is a new thing as of ES2015.

In specification terms, it creates an identifier binding on the Declarative Environment Record for the global environment rather than the Object Environment Record. The global environment is unique in having a split Environment Record, one for all the old stuff that goes on the global object (the Object Environment Record) and another for all the new stuff (let, const, and the functions created by class) that don't go on the global object, but go in the global environment's Declarative Environment Record instead.

The binding is created before any step-by-step code in its enclosing block is executed (in this case, before any global code runs), but it's not accessible in any way until the step-by-step execution reaches the let statement. Once execution reaches the let statement, the variable is accessible. (See "When let and const happen" below.) The time between the binding being created (on entry to the scope) and becoming accessible (code execution reaching the let) is called the Temporal Dead Zone [TMZ]. While the binding is in that state, any attempt to read from it or write to it is a runtime error.

(The specification's terminology for whether the binding is accessible is whether it's "initialized," but don't confuse that use of "initialized" with having an initializer on the let statement [let a = 10; vs. just let a;]; they're unrelated. The variable defined by let a; is initialized with undefined once the let is reached.)

1.2 const a = 0;

Creates a global constant, which is not a property of the global object.

A const binding is exactly like a let binding (including the TMZ and such) except it has a flag saying its value cannot be changed. One implication of that is you must provide an initializer (the = value part) to provide the initial (and never-changing) value for the const.

Using const does three things for you:

1. Makes it a runtime error if you try to assign to the constant (and most IDEs will flag it up for you more proactively than that).
2. Documents its unchanging nature for other programmers.
3. Lets the JavaScript engine optimize on the basis that the const's value won't change (without having to track whether it's written to later or not — e.g., doesn't have to check if it's effectively constant).

It's important to understand that the const's value never changing doesn't mean that an object the const refers to is immutable. It isn't. It just means that the value of the const can't be changed so it refers to a different object (or contains a primitive):

Copy// This is fine:
const x1 = {a: 1};
console.log(x1.a); // 1
x1.a = 2;
//^^^^^^−−− No problem, just changing the object's state, not the value in the `const` (the object reference)
console.log(x1.a); // 2

// This is not:
const x2 = {a: 1};
console.log(x2.a); // 1
x2 = {a: 2};
// ^−−−−−−− Error here ("TypeError: Assignment to constant variable"),
// you can't change the value of a `const`
console.log(x2.a);

2 a = 0;

Don't do this. It's assigning to a completely undeclared identifier. In loose mode (the only mode before ES5), it creates a property on the global object implicitly. On my old blog, I call this The Horror of Implicit Globals. Thankfully, they fixed it with strict mode, added in ES5 and the default in new kinds of scopes (inside modules, inside class constructs, etc.). Strict mode makes assigning to an undeclared identifier the error it always should have been. It's one of several reasons to use strict mode.

Since it creates a normal property, you can delete it.

The property this creates is enumerable (except on the very obsolete IE8 and earlier).

3 window.a = 0; or globalThis.a = 0;

This creates a property on the global object explicitly, using the window global (on browsers) or the globalThis global that refers to the global object. As it's a normal property, you can delete it.

This property is enumerable (even on the very obsolete IE8 and earlier).

4 this.a = 0;

Exactly like #3, except we're referencing the global object through this instead of the globals window or globalThis. This works because this at global scope is the "global" this value. This is true even in strict mode. (Strict mode changes the this used when you call a function without supplying this, such as when you do fn(), but not what this is at global scope.) Note that it has to really be global scope. The top-level scope of modules is not global scope (it's module scope), and at module scope this is undefined.

Deleting properties

What do I mean by "deleting" or "removing" a? Exactly that: Removing the property (entirely) via the delete keyword:

Copywindow.a = 0;
console.log(`"a" in window? ${"a" in window}`); // "a" in window? true
delete window.a;
console.log(`"a" in window? ${"a" in window}`); // "a" in window? false

delete completely removes a property from an object. You can't do that with properties added to window indirectly via var, the delete is either silently ignored or throws an exception (depending on whether you're in strict mode).

(Minor note: The very obsolete IE8 and earlier, and the obsolete IE9-IE11 in their broken "compatibility" mode, wouldn't let you delete window properties even if you should have been allowed to.)

When var happens

Preface: var has no place in new code. Use let or const instead. But it's useful to understand var for the purposes of understanding old code you run across.

The variables defined via the var statement are created before any step-by-step code in the execution context is run, and so the variable (and its property on the global object) exists well before the var statement.

This can be confusing, so let's take a look. Here we have code trying to access a and b, followed by code in the middle creating them, and then code trying to access them again:

Copytry {
    console.log(a);   // undefined
    console.log(b);   // ReferenceError: b is not defined
} catch (e) {
    console.error(e);
}

var a = "ayy";
b = "bee";            // Don't do this, but I didn't want to use `let` or `const` in this example

try {
    console.log(a);   // "ayy"
    console.log(b);   // "bee"
} catch (e) {
    console.error(e);
}

As you can see, the identifier a is defined (with the value undefined) before the first line runs, but the identifier b isn't, so trying to read its value is a ReferenceError. The statement var a = "ayy"; really deos two different things, at different times: On entry to the scope, it defines the identifier with the initial value undefined (the var a part), and later when it's reached in the execution of the code, it sets the value of a (the a = "ayy" part). Since a is defined before the first line of code runs, we can use it (and see its undefined value). This is known as "var hoisting" because the var a part is moved ("hoisted") to the top of the global scope or function scope where it appears, but the a = "ayy" part is left in its original location. (See Poor misunderstood var on my anemic old blog.)

When let and const happen

let and const are different from var in a couple of useful ways. The ways that are relevant to the question are A) that although the binding they define is created before any step-by-step code runs, it's not accessible until the let or const statement is reached; and B) as we've seen above, at global scope they don't create properties on the global object.

Re (A), while this using var runs:

Copyconsole.log(a); // undefined
var a = 0;
console.log(a); // 0

This using let throws an error:

Copyconsole.log(a); // ReferenceError: a is not defined
let a = 0;
console.log(a);

window.variableName means that the variable is being declared at the global scope. This means any JS code will have access to this variable. Using window. is not necessary but is frequently used as a convention to denote that a variable is global.

Globals are generally to be avoided. You should define variables within the scope of functions.