The old var & the global object

Why old globals still matter

Modern JavaScript code usually lives in modules. A module is a file loaded with import, or with <script type="module">. Modern code also makes its variables with let and const. But a lot of code you will read is older. You'll find it in analytics tags, copied browser snippets, and old libraries. That older code often does three things:

• It makes variables with var.
• It expects its names to show up on window.
• It sometimes makes global names by accident.

This lesson builds on three earlier lessons:

• The Variables lesson told you to avoid var.
• The Execution contexts lesson showed the global execution context: the setup JavaScript makes before the first line of a script runs.
• The Strict mode lesson showed how modern JavaScript turns silent mistakes into errors.

Now you'll see what var really does, so old code makes sense when you meet it.

One note about this page. The lesson files on this site are modules. So if this page itself used a top-level var, it would not create a window property, and a typo would throw an error. To show the old behavior for real, the lab further down runs classic scripts inside a sandboxed iframe: a small, locked-down page inside this page. The tests for this lesson also check the classic-script behavior with Node's vm module, which can run code as a classic script.

var has function scope. That means a var written anywhere inside a function belongs to the whole function. A block is code inside braces { }, such as the body of an if or a for. A block does not make a new scope for var. let and const are different. They have block scope: they belong only to their block.

1function showCart() {2  if (true) {3    var item = "tea";4  }5  console.log(item);6}7showCart();

Line 3 sets item inside the if block. Line 5 is after the block, but it can still read item. That's because var puts item in the whole showCart function. The console prints tea. If line 3 used let item instead, item would exist only inside the braces, and line 5 would throw a ReferenceError.

Now try it yourself. The next example has the same shape. Switch line 3 between var and let, then step through the code one line at a time. This small difference explains many bugs in old code.

1function readNotice(show) {Run2  if (show) {3    var notice = "Lobby board";4  }5  console.log(notice);6}7readNotice(true);

With var, line 5 can read notice after the if block. With let, line 5 is outside the block where notice lives, so it throws a ReferenceError.

The step-through also shows that a var name exists from the start of the function, set to undefined, before line 3 gives it a value. The Hoisting & the temporal dead zone lesson, coming up later, explains why. For now, remember one rule: var belongs to the nearest function around it. If there is no function, it belongs to the whole script.

1function readNotice(show) {2  if (show) {3    var notice = "Lobby board";4  }5  console.log(notice);6}7readNotice(true);

To declare a variable means to create it with var, let, or const. To redeclare it means to declare the same name again in the same scope. var allows this. The second var does not make a new variable. It reuses the same one. That made old scripts forgiving. But it also made it easy to reuse a name by mistake and never notice.

let and const refuse a second declaration of the same name in the same scope. Two variables with the same name in one place would make it unclear which one you mean.

1var status = "draft";2var status = "published";3console.log(status);

Lines 1 and 2 declare the same variable, status. Line 2 also gives it a new value. So line 3 prints published. There is only one status, not two.

1var status = "draft";2var status = "published"; // allowed: same binding3 4let mode = "dark";5let mode = "light"; // SyntaxError before this script can run

A SyntaxError is not like other errors. JavaScript reads the whole script before it runs it. If it finds a grammar mistake, like a repeated let, it rejects the whole script and runs no line of it. Other errors, like ReferenceError, happen while the code is running.

In the iframe lab in the next section, the bad let lines sit in their own <script> tag. That way, the other scripts still run and can report the error.

The global object is an object whose properties every script can use without importing anything. The host makes it. The host is the program that runs your JavaScript, like a browser or Node.js. Each host has its own global object:

• In a browser page, the global object is window, so globalThis === window is true. The browser also gives it other names, such as self and frames.
• In a web worker (a script that runs in the background, apart from the page), there is no window. globalThis points at the worker's global object.
• In Node.js, globalThis points at Node's global object.

globalThis was added to JavaScript so code can say "the global object" in every host. You don't need to guess whether the host calls it window, self, or something else.

The lab below runs a few classic scripts inside a sandboxed iframe. Next to the code, it lists what each script created. Click "Run the sandbox again" to run them once more.

1<script>2var classicCount = 1;3let lexicalCount = 2;4function classicTool() {}5implicitName = "Ada";6var name = 123;7</script>

A browser page starts with many names already on window. For example, window.status already exists and holds a string, even though modern pages rarely use it. Before you add a global name, check that the browser or another script doesn't already use it.

In a classic browser script, "global" can mean two different places:

• The global object, window. Top-level var and function declarations go here, as properties.
• A separate list of global names for top-level let, const, and class. The specification (the official rule book for JavaScript) calls this list the global lexical environment. "Lexical" means "decided by where the code is written".

Every classic script on the page can use names from both places. But only names in the first place show up as window.someName.

1var cart = "tea";2let checkoutNote = "private";3function checkout() {}4console.log(globalThis.cart);5console.log(globalThis.checkoutNote);6console.log(typeof globalThis.checkout);

Line 4 finds cart as a property of globalThis and prints tea. Line 5 finds no property called checkoutNote, because a top-level let is not stored on the global object. It prints undefined. Line 6 finds checkout as a property. typeof gives the type of a value as text, so line 6 prints function.

The table below lists the three places a top-level name can live. Read each row as: "this kind of name is made by this code, and here is whether you can see it on window."

Now sort each declaration by one question: does it become a window property? Check whether the card says it is inside a module.

Implicit globals: a typo that makes a global

Code that is not in strict mode is often called sloppy mode. In a sloppy classic script, you can assign to a name that was never declared, and JavaScript doesn't complain. It adds that name to the global object as a new property. This is called an implicit global: a global made without any declaration. It usually starts as a typo.

1function saveUser() {2  let name = "Ada";3  nmae = name; // typo: creates a global in sloppy classic scripts4}5saveUser();6console.log(globalThis.nmae);

Line 2 declares name. Line 3 misspells it as nmae. No nmae was ever declared, so in sloppy mode line 3 creates globalThis.nmae. Line 5 runs the function, and line 6 reads the new property. The console prints Ada.

In strict mode, line 3 throws a ReferenceError instead. Modules always run in strict mode. That is one reason modules are safer.

1"use strict";2function saveUser() {3  nmae = "Ada";4}5saveUser();

Here line 1 turns on strict mode. Line 5 calls saveUser, which runs line 3. In strict mode, an unknown name never turns into a global. So line 3 throws a ReferenceError before the function finishes. You see the typo the first time you test the code.

Global pollution means putting too many names into the shared global space. It isn't just messy. It causes real bugs:

• Two scripts pick the same name, and one replaces the other. This is called a collision.
• Tests pass only when the scripts load in one certain order.
• Your app code replaces a library's function by accident.

In the demo below, two scripts both create config and $. Use the button to switch between classic scripts and modules, and watch what the app sees.

1// library-a.js2var config = { theme: "dark" };3function $(selector) { return "A:" + selector; }4 5// app.js, loaded later6var config = { theme: "light" };7function $(selector) { return "B:" + selector; }

1// library-a.js2var config = { theme: "dark" };3function $(selector) { return "A:" + selector; }4 5// app.js, loaded later6var config = { theme: "light" };7function $(selector) { return "B:" + selector; }8 9console.log(config.theme);10console.log($("button"));

Lines 2 and 3 come from the library. Lines 6 and 7 come from the app, which loads later and uses the same names. Line 9 prints light, and line 10 prints B:button. The app's versions replaced the library's.

Here are ways to fix it, from strongest to weakest:

1. Use modules. Each file keeps its own names and shares only what it exports.
2. Wrap old code in an IIFE (an immediately invoked function expression). That is a function that runs right away, like (function () { ... })();. Names made inside it stay inside it.
3. Keep one shared object on purpose, such as globalThis.CompleteFrontend, and put the shared names inside it. This one object is called a namespace.
4. Declare every name with let, const, or var, so a typo can't make a new global.

The Closure patterns lesson shows IIFEs. The Why modules? lesson, coming later, returns to this problem.

Sharing one global on purpose

Most app code should live in modules. But sometimes an old page or a plugin needs one public entry point. Then make it easy to see:

• Create one object on globalThis.
• Put a small set of functions inside it.
• Keep every helper name private.

1globalThis.CompleteFrontend = {2  version: "1.0",3  saveUser(name) { return "saved " + name; },4};5 6console.log(globalThis.CompleteFrontend.saveUser("Asha"));

Line 1 creates the one shared object, CompleteFrontend. Line 3 gives it a saveUser method, the only thing this example shares. Line 6 calls it through the object, so the output is saved Asha. One object means fewer collisions. But every script can still change it, so modules are still the better choice.

The delete operator removes a property from an object. It gives true if the property is gone, and false if it could not be removed.

1var oldHook = "legacy";2globalThis.newHook = "intentional";3 4console.log(delete globalThis.oldHook);5console.log(delete globalThis.newHook);6console.log(globalThis.oldHook);7console.log(globalThis.newHook);

Line 4 prints false. A top-level var makes a property that is non-configurable, which means it cannot be deleted. Line 5 prints true, because a property you add with = can be deleted. Lines 6 and 7 print legacy and undefined: oldHook is still there, and newHook is gone. Don't use delete to clean up a global you did not create.

1// module.mjs2var moduleCount = 1;3let moduleMessage = "private";4console.log(globalThis.moduleCount);5console.log(globalThis.moduleMessage);

This example only works as a module file, so it has no Run button: the code boxes on this page run code as classic scripts. In a real .mjs file (a file Node.js loads as a module), lines 4 and 5 both print undefined. The module can use its own names, but it doesn't put them on globalThis.

Answer each question from memory first. Then read every explanation. The wrong choices are real mistakes people make with old code.

Key takeaways

• var belongs to the whole function, not to the block it is written in.
• You can declare the same var twice, and it is still one variable. let and const refuse a second declaration in the same scope.
• In a classic browser script, a top-level var or function becomes a window property. A top-level let or const does not.
• In sloppy mode, assigning to a name that was never declared makes an implicit global, usually by mistake. Strict mode and modules stop this.
• Too many globals cause collisions. Use modules first. If you can't, use an IIFE or one namespace object, and always declare your names.

Up next: The this keyword, which explains what this means in each call.