Skip to content
JavaScript js scope-closures 5 min read

Execution Context & Call Stack

Every line of JavaScript runs inside an execution context — an internal bookkeeping structure the engine builds to track which variables exist, what this refers to, and where to resume when a function returns. The engine stacks these contexts on a call stack, pushing one each time a function is invoked and popping it when the function finishes. Understanding this model demystifies hoisting, scope, this, and the cryptic stack traces you see in errors.

What an execution context is

An execution context is the environment in which a piece of code is evaluated. The engine creates one of three kinds: the single global execution context (created once when your program starts), a new function execution context for every function call, and an eval context (rarely used). Each context holds three things: a reference to its variable environment (the bindings declared inside it), a reference to its outer lexical environment (for scope lookups), and the value of this.

The global context represents top-level code. In a browser its this is the window object; in Node.js module scope it is module.exports (an empty object), while in a CommonJS function wrapper top-level this differs from the global object. Every function call layers a fresh context on top of whatever is already running.

The two phases: creation and execution

Each context is processed in two phases. During the creation phase, the engine scans the code and sets up the environment before running a single statement: it allocates memory for variables and functions (this is what makes hoisting possible), determines the this binding, and links the outer environment. function declarations are stored fully; var bindings are initialized to undefined; let and const are recorded but left uninitialized in the “temporal dead zone”.

During the execution phase, the engine runs the code top to bottom, assigning values and invoking functions. When it hits a function call, it pauses the current context, creates a new one for the callee, and that new context goes through its own creation and execution phases.

function multiply(a, b) {
  return a * b;
}

function square(n) {
  return multiply(n, n);
}

console.log(square(5));

Output:

25

When square(5) runs, the engine creates a context for square, which calls multiply, creating another context on top. multiply returns, its context is destroyed, control returns to square, which returns to the global context.

The call stack

The call stack is a LIFO (last-in, first-out) structure of execution contexts. The global context sits at the bottom for the lifetime of the program. Each call pushes a frame; each return (or reaching the end of the function) pops it. The frame on top is the code currently executing.

This is the same stack you see, top frame first, in any error’s .stack property — and it is the structure that overflows when recursion never terminates.

Call stack while multiply() is executing:

  ┌─────────────────────────┐  ← top (currently running)
  │  multiply(5, 5)         │
  ├─────────────────────────┤
  │  square(5)              │
  ├─────────────────────────┤
  │  global execution ctx   │  ← bottom (always first)
  └─────────────────────────┘

After multiply returns, its frame is popped; square returns next, then global remains.

You can observe the order directly:

function first() {
  console.log("enter first");
  second();
  console.log("exit first");
}

function second() {
  console.log("enter second");
}

first();

Output:

enter first
enter second
exit first

"exit first" only prints after second has fully returned and its frame is popped, because first cannot resume until the frame above it is gone.

How this and variables are set up

The this binding is resolved per context during creation, based on how the function was called — not where it was defined. A plain call sets this to undefined in strict mode (or the global object otherwise); a method call sets it to the receiver; new sets it to the fresh instance; and call/apply/bind set it explicitly. Arrow functions are the exception: they have no this of their own and inherit it from the enclosing context’s lexical environment.

Call formthis value (strict mode)
fn()undefined
obj.fn()obj
new Fn()the new instance
fn.call(ctx) / fn.apply(ctx)ctx
Arrow functioninherited from enclosing scope

Variable lookups walk the chain of outer lexical environments, not the call stack. The call stack tracks when code runs; the lexical environment chain tracks what a name resolves to. This distinction is why closures work even after a function’s stack frame has been popped.

The call stack and the scope chain are different things. The stack is about execution order (who called whom); the scope chain is about name resolution (where a variable was defined). A function called from a deeply nested stack still resolves its variables against its definition environment.

Stack overflow

Because the stack has a finite size, unbounded recursion pushes frames until the engine throws.

function recurse() {
  return recurse();
}

recurse();

Output:

RangeError: Maximum call stack size exceeded

Each call adds a frame that is never popped because the function never returns. Always ensure recursion has a base case that lets frames unwind.

Best practices

  • Treat the call stack as the source of truth when reading stack traces — the top frame is where the error actually occurred.
  • Remember that this is decided by how a function is called, so bind or use arrow functions when you need a stable this.
  • Give recursive functions a clear base case to avoid RangeError: Maximum call stack size exceeded.
  • Don’t confuse the call stack (execution order) with the scope chain (name resolution); they answer different questions.
  • Keep functions small and well-named so stack traces read like a meaningful narrative of what happened.
  • Reach for iteration or a trampoline when recursion depth could exceed the stack limit on large inputs.
Last updated June 1, 2026
Was this helpful?