Execution contexts

Every run starts with a workspace

Before your code does any work, JavaScript gets ready to run it. It makes a workspace for that code. This workspace is called an execution context. JavaScript makes one for the whole script, and one more for each function call.

An execution context keeps three things together:

• The names the code can use, like its variables and functions, with their values.
• An outer link: where to look next when a name isn't found here.
• The value of this for the code that is running.

This lesson uses a simple model of contexts. The model tells you correctly what your code will do. Real engines store things in faster, more complex ways, and later lessons show the exact rules from the specification. You already know variables, local variables inside functions, closures, and strict mode. Execution contexts show how those ideas fit together while code runs.

The first context JavaScript makes is the global execution context. Code that is not inside any function is called top-level code, and it runs here. Functions written at the top level are also set up here.

When you call a function, JavaScript makes a new context for that call and puts it on top of the global one. When the function finishes, that context is removed. The next lesson, The call stack, looks closely at this adding and removing.

The global context comes with the global object. This is an object that holds things every script can use, like console and setTimeout. Browsers call it window. Browsers, Node.js, and every other place that runs JavaScript also call it globalThis. The global object is only part of the global context. In a normal script, a top-level let or const is a global variable, but it does not become a property of globalThis.

1function announce(label) {2  let message = label + " #" + count;3  console.log(message);4}5 6var status = "draft";7let count = 1;8count = count + 1;9announce("Article");

This code starts in the global context. Lines 1 to 3 write the function announce, but its body does not run yet. It runs only when line 9 calls the function. That call makes a new context, with its own parameter label and its own local variable message.

1function greet(user) {2  const message = "Hi, " + user;3  return message;4}5 6console.log(greet("Asha"));

Line 6 calls greet("Asha"). JavaScript makes a context for this call. In it, the parameter user holds "Asha". Line 2 makes a local variable, message, that joins the greeting and the name. The function returns it, so line 6 prints Hi, Asha.

Every context is used in two steps, called phases:

• The creation phase comes first. JavaScript reads the code and sets up its declarations. A declaration is a line that makes a name, like var x, let x, or function f() {}. No line runs yet.
• The execution phase comes next. JavaScript runs the lines one by one, from top to bottom, and changes values.

In the creation phase, each kind of declaration is set up in its own way:

• A function declaration is ready to call right away.
• A var name is made and given the value undefined.
• A let or const name is made, but it has no value yet. Reading it before its line runs throws a ReferenceError.

The table below uses the script from above. Read each row as: this name, made this way, holds this before any line runs, and this after the script finishes.

1console.log(greet());2 3function greet() {4  return "ready";5}

Line 1 calls greet, but the function is written below it, on line 3. This still works. The creation phase already made the function ready. Its body runs only because line 1 calls it, so the output is ready.

Now step through the script from above. The first step shows what the creation phase set up. The later steps are recorded from real JavaScript that runs the same code and prints the same output.

1function announce(label) {Run2  let message = label + " #" + count;3  console.log(message);4}5 6var status = "draft";7let count = 1;8count = count + 1;9announce("Article");

A later lesson, Hoisting & the temporal dead zone, goes deeper. For now, remember one rule: all declarations are set up before the code runs, but only some of them can be used before their own line.

1console.log(ready);2var ready = "yes";3 4console.log(count);5let count = 1;

Line 1 reads ready before line 2 gives it a value. The creation phase already made ready with undefined, so line 1 prints undefined. Line 4 reads count before line 5. The name count exists, but it has no value yet, so line 4 throws a ReferenceError. The time between the start of the code and the let line is called the temporal dead zone, or TDZ. During the TDZ, the name exists but can't be read.

A context keeps its names in lists. You will hear two words for these lists. In this lesson they mean:

• The variable environment is the list that var names go into. There is one for each function call, and one for the global context.
• A lexical environment is a list for let, const, and parameters. "Lexical" means "decided by where the code is written". Each block, like the inside of an if, can get its own lexical environment.

The specification has a more exact version of these lists, called Environment Records. A later lesson covers them.

Each list also has an outer link. It points to the list around the place where the function was written. When code uses a name, JavaScript looks in the current context first. If the name isn't there, JavaScript follows the outer link and looks there, and so on. The Closures lesson uses this same outer link: a function remembers the place it was written.

1const room = "global";2function outer() {3  const room = "outer";4  inner();5}6function inner() {7  const task = "inspect";8  console.log(room, task);9}10outer();

1const room = "home";2function showRoom() {3  const room = "kitchen";4  console.log(room);5}6 7showRoom();8console.log(room);

Line 3 makes a second room, inside showRoom. When line 7 calls the function, line 4 finds the inner room first and prints kitchen. The inner name hides the outer one. This is called shadowing. Line 8 runs in the global context, so it prints the outer home. JavaScript follows the outer link only when the current context has no name that matches.

1const place = "home";2 3function makeGreeting() {4  const user = "Asha";5  function greeting() {6    return user + " at " + place;7  }8  return greeting();9}10 11console.log(makeGreeting());

Line 6 is inside greeting, and it needs user and place. Neither is made inside greeting. So JavaScript follows the outer link to makeGreeting, where greeting was written, and finds user on line 4. It follows the next outer link to the global context and finds place on line 1. Line 11 prints Asha at home.

The outer link depends on where a function is written, not on who calls it. Calling a function from inside another function does not change where it looks.

The table below sums up the three words. Read each row as: this word, what it means, which names go there, and where you will notice it.

globalThis is the standard name for the global object. In a browser, globalThis === window is true in normal code. But the value of this at the top level depends on how the file is loaded. There are two ways to load a file:

• A classic script is a normal <script> tag. Its code is not in strict mode unless it asks for it. Code that is not in strict mode is sometimes called sloppy mode.
• An ES module is a file loaded with <script type="module"> or with import. A module is always in strict mode.

Here is what changes between them:

• In a classic script in sloppy mode, top-level this is globalThis.
• In an ES module, top-level this is undefined.
• The top-level names in a module stay inside that module. They never go on globalThis.

Inside a normal function, this works differently. It is decided by how the function is called, each time it is called. A function does not copy this from the code around it.

1var scriptVar = "var property";2function scriptFunction() {3  return "function property";4}5let scriptLet = "lexical only";6const scriptConst = "lexical only";7 8console.log(this === globalThis);9console.log(globalThis.scriptVar);10console.log(globalThis.scriptFunction());11console.log(globalThis.scriptLet);12console.log(globalThis.scriptConst);

The table below compares four places. Read each row as: code running here has this this, and its top-level names go here.

1const cart = {2  label: "tea",3  readLabel() {4    return this.label;5  },6};7 8const read = cart.readLabel;9console.log(cart.readLabel());10console.log(read());

Line 9 calls cart.readLabel(). The object before the dot, cart, becomes this, so it prints tea. Line 8 saved the same function into read, without its object. Line 10 calls read() with nothing before it. This code is in sloppy mode, so this becomes globalThis. There is no globalThis.label, so it prints undefined.

1var scriptVar = "var property";2function scriptFunction() {3  return "function property";4}5let scriptLet = "lexical only";6const scriptConst = "lexical only";7 8console.log(this === globalThis);9console.log(globalThis.scriptVar);10console.log(globalThis.scriptFunction());11console.log(globalThis.scriptLet);12console.log(globalThis.scriptConst);

In this classic script, line 8 prints true: top-level this is globalThis. Lines 9 and 10 find scriptVar and scriptFunction on globalThis. Lines 11 and 12 print undefined, because let and const names don't go there.

1var moduleVar = "not a global property";2let moduleLet = "module lexical";3const moduleConst = "module lexical";4function moduleFunction() {5  return "module function";6}7 8console.log(this === undefined);9console.log(globalThis.moduleVar);10console.log(globalThis.moduleFunction);11console.log(typeof moduleLet);12console.log(typeof moduleConst);

In this module, line 8 prints true: top-level this is undefined. Lines 9 and 10 print undefined, because even var and function names stay in the module. Lines 11 and 12 print string, because the module itself can still use its own names.

Where you'll use this

Execution contexts explain several bugs you will meet in real code:

• A var prints undefined before the line that gives it a value. The creation phase made it with undefined.
• A let read throws before its line. That read is in the temporal dead zone.
• A helper function reads or changes a global variable by accident. Now it depends on the global context, which every script on the page shares.

1function scoreLabel(score) {2  var prefix = "Score";3  return prefix + ": " + score;4}5console.log(scoreLabel(9));6console.log(globalThis.prefix);

Line 2 makes prefix inside the function, so it lives in the function's own context. Line 5 prints Score: 9. After the call, line 6 shows that globalThis.prefix is still undefined. This is safer than a global var, which every script on the page can read and change.

Common misconceptions

Make a guess before you choose. Every answer explains the rule it uses, so a wrong guess still teaches you something.

Key takeaways

• An execution context is the workspace JavaScript makes to run the whole script or one function call.
• The global execution context is made first. Each function call makes one more context on top.
• The creation phase sets up declarations. The execution phase runs the lines and changes values.
• A var name starts as undefined. A let or const name can't be read before its line: that time is the TDZ.
• Scripts and modules differ. In a module, top-level this is undefined, and top-level names don't go on globalThis.

Up next: The call stack. You will see how JavaScript adds a context each time a function is called, and removes it when the function returns.