Course: JavaScript Advanced

Lesson 1: Execution Context

Level

Advanced

Estimated Reading Time

10–15 minutes

Goal

By the end of this lesson, the learner will be able to:

• Explain what an execution context is and how the call stack works
• Describe the difference between the global execution context and function execution contexts
• Trace how JavaScript creates, uses, and destroys execution contexts when running code

Frontend Development Context

Every time your JavaScript runs — whether a button click fires, an async function resolves, or a module loads — the JavaScript engine creates an execution context to manage that code. Understanding execution contexts explains behaviors that otherwise seem mysterious: why var declarations are undefined before their line runs, why the call stack overflows with infinite recursion, and how hoisting works under the hood. These are not abstract concepts; they directly affect how your UI code behaves in the browser.

At the advanced level, knowing the execution model lets you reason about code order, debug unexpected undefined values during initialization, and understand why certain async patterns behave the way they do. When you can mentally simulate what the JavaScript engine does, debugging becomes faster and architectural decisions become more deliberate.

Explanation

When JavaScript starts running a script, the engine creates a global execution context. This context has two phases: the creation phase, where variables and function declarations are hoisted into memory, and the execution phase, where the code actually runs line by line. The global context creates a global object (window in browsers) and sets up the this binding for the top level.

Every time a function is called, a new function execution context is pushed onto the call stack. This context has its own variable environment, its own this binding, and a reference to its outer environment (which is how scope chains are formed). When the function returns, its context is popped off the stack.

The call stack is a last-in, first-out structure. If function A calls function B, and B calls C, the stack holds [global, A, B, C]. When C returns, it pops off; then B returns and pops off; and so on back to A. If you cause infinite recursion — a function that keeps calling itself — the stack eventually exceeds its limit and throws a RangeError: Maximum call stack size exceeded.

Hoisting is a direct consequence of the creation phase. During creation, var declarations are placed in memory and initialized to undefined. Function declarations are placed in memory fully — both the name and the function body. let and const are hoisted too, but not initialized, which creates the temporal dead zone: accessing them before their declaration line throws a ReferenceError.

Understanding this two-phase model also clarifies closures, this binding, and why module-level code behaves differently from function-level code. The execution context is the foundation that all other advanced JavaScript concepts build on.

Code Example

This example traces what the call stack looks like as three functions interact, and shows how hoisting affects a var declaration vs. a let declaration.

console.log(typeof hoistedVar);   // "undefined" — hoisted, initialized to undefined
console.log(typeof hoistedFn);    // "function" — fully hoisted

// console.log(blockScoped);      // would throw ReferenceError (temporal dead zone)

var hoistedVar = "I was hoisted";
let blockScoped = "I was not initialized during hoisting";

function hoistedFn() {
  return "function declarations are fully hoisted";
}

function outer() {
  const outerVal = "outer";

  function middle() {
    const middleVal = "middle";

    function inner() {
      // Call stack here: [global, outer, middle, inner]
      return `${outerVal} > ${middleVal} > inner`;
    }

    return inner();
  }

  return middle();
}

console.log(outer()); // "outer > middle > inner"

function factorial(n) {
  if (n <= 1) return 1;
  return n * factorial(n - 1); // each call pushes a new context
}

console.log(factorial(5)); // 120 — call stack depth: 5

Code Explanation

The first two console.log calls run before the var and function declarations appear in the source. They both work because the creation phase already placed them in memory: hoistedVar is undefined and hoistedFn is the full function. The commented-out line for blockScoped would throw because let is in the temporal dead zone.

The outer, middle, and inner functions illustrate nested execution contexts. When outer() is called, a new context is created with outerVal in its variable environment. Calling middle() creates another context with middleVal. Inside inner, the call stack holds four frames simultaneously. Each function can access variables from outer contexts through the scope chain, which is formed at context creation time.

The factorial function shows how the call stack grows with each recursive call. factorial(5) calls factorial(4), which calls factorial(3), and so on. Each call is a new execution context pushed onto the stack. Only when the base case returns does the stack start unwinding, multiplying results on the way back up.

This model — creation phase, execution phase, scope chain, call stack — is what the JavaScript engine actually does. Every other advanced concept in this course (closures, this, async, modules) depends on this foundation.

Pattern Highlights

✅ Positive Pattern: Use let and const instead of var to avoid relying on hoisting behavior, which makes code execution order explicit and prevents bugs from temporal dead zone surprises.

⚠️ Neutral Note: The call stack has a finite size (typically around 10,000–15,000 frames in V8). Deep recursion that processes large datasets should be converted to an iterative approach or use trampolining.

❌ Negative Pattern: Do not assume a var variable has a meaningful value before its assignment line — it will be undefined during the creation phase, which can cause silent bugs that are hard to trace.

Common Mistakes

Mistake 1: Relying on var hoisting for readability

Using a var before declaring it exploits hoisting but produces confusing code that reads as if the variable is already set.

function showLabel() {
  console.log(label); // undefined — not the string you expect
  var label = "Submit";
  console.log(label); // "Submit"
}
showLabel();

The first log prints undefined because var is hoisted but not yet assigned. Using let here would throw a clear ReferenceError instead of silently passing undefined through your UI logic.

Mistake 2: Causing an accidental infinite call stack

Writing a recursive function without a base case, or with a base case that is never reached, will crash the JavaScript engine with a stack overflow.

function countDown(n) {
  console.log(n);
  countDown(n - 1); // no base case — runs until RangeError
}
countDown(5);

Every recursive function needs a condition that stops the recursion. The engine cannot recover from a stack overflow — it terminates the current script.

Mistake 3: Misunderstanding when global context code runs

Developers sometimes write initialization code at the module or script top level expecting it to run after DOM is ready, but the global execution context runs immediately when the script is parsed.

const btn = document.querySelector("#submit"); // null if DOM isn't ready yet
btn.addEventListener("click", handleClick);    // TypeError: Cannot read properties of null

Script tags without defer or type="module" run before the DOM is fully parsed. Use defer, place scripts at the end of <body>, or wrap initialization in a DOMContentLoaded listener.

Quick Recap

• JavaScript creates an execution context (creation phase + execution phase) for every function call and for the global scope.
• The call stack tracks active execution contexts in last-in, first-out order; returning from a function pops its context off the stack.
• var declarations are hoisted and initialized to undefined; function declarations are fully hoisted; let and const are hoisted but not initialized (temporal dead zone).
• Every other advanced JavaScript concept — closures, scope chains, this, async — is built on top of how execution contexts work.