JavaScript Execution Context

Introduction

Every line of JavaScript you write eventually runs inside an execution context — the environment the engine creates to manage variables, this, scope, and the order in which code executes. Understanding execution context is not optional trivia; it is the foundation behind scope, closures, hoisting, and the this keyword.

This guide walks from source code to machine execution:

1. What execution context is and why it matters
2. How the engine processes code before it runs
3. Lexical environment vs execution context
4. Global and function execution contexts
5. Creation and execution phases
6. The call stack
7. Stack vs heap memory

Each section includes runnable examples you can paste into the browser console or Node.js.

Course Reference

Quick index

1. What is execution context?

An execution context is the environment in which JavaScript code is evaluated and executed. Think of it as a container the engine builds for a specific chunk of code — global script, a function body, or an eval block.

Every context has three essential components:

When JavaScript starts running a file, it does not jump straight into line-by-line execution. It first creates a context, sets up memory for variables and functions, then runs the code inside that context.

const greeting = 'Hello'
 
function sayHello(name) {
  const message = `${greeting}, ${name}!`
  console.log(message)
}
 
sayHello('Kazi')
// "Hello, Kazi!"

Running this script involves at least two contexts: one for the global script and one created each time sayHello is invoked.

Back to index

2. Why it matters

Execution context is the invisible infrastructure behind several concepts you use every day.

Scope and closures

Scope is not a static label on a block of code — it is determined by the lexical environment attached to an execution context. Closures exist because a function retains access to the lexical environment from the context where it was created, even after that outer context has finished executing.

function createCounter() {
  let count = 0
  return function () {
    count++
    return count
  }
}
 
const counter = createCounter()
console.log(counter()) // 1
console.log(counter()) // 2

The inner function closes over the variable environment of createCounter's execution context.

The this keyword

this is not resolved by where a function is written — it is bound when the function's execution context is created. That binding depends on how the function is called (global, method, constructor, call/apply/bind, arrow function).

const user = {
  name: 'Kazi',
  greet() {
    console.log(this.name)
  },
}
 
user.greet() // 'Kazi' — `this` is `user`
 
const fn = user.greet
fn() // undefined in strict mode — `this` is not `user`

Hoisting and temporal dead zone

During the creation phase, the engine allocates memory for declarations before any line runs. That is why function declarations appear available before their definition line, and why let/const exist in a temporal dead zone until their declaration line executes.

Back to index

3. How the engine processes code

Before JavaScript executes anything, the engine transforms your source code through several stages.

Source Code → Tokenization → AST → Compilation → Machine Code → Execution

// What you write
function add(a, b) {
  return a + b
}
 
add(2, 3)

The engine does not execute this character by character. It parses the entire function into an AST, compiles it, then creates an execution context when add is called.

Back to index

4. Lexical environment vs execution context

These two terms are related but not interchangeable.

A lexical environment is a record with:

• An environment record (variable bindings)
• A reference to an outer lexical environment (parent scope)

An execution context contains a lexical environment plus the this binding and other runtime metadata.

const outer = 'global'
 
function outerFn() {
  const middle = 'middle'
 
  function innerFn() {
    const inner = 'inner'
    console.log(inner, middle, outer)
  }
 
  innerFn()
}
 
outerFn()
// 'inner' 'middle' 'global'

When innerFn runs, its lexical environment links outward: innerFn → outerFn → global. The execution context for innerFn uses that chain to resolve middle and outer.

Back to index

5. Global execution context (GEC)

The Global Execution Context is created automatically when a JavaScript program starts. There is exactly one GEC per runtime (per tab in the browser, per Node.js process).

// Browser (non-module script)
var title = 'Blog'
console.log(window.title) // 'Blog'
 
function showGlobal() {
  console.log(this === window) // true in browser, non-strict
}
showGlobal()

In ES modules (type="module"), top-level variables are scoped to the module — they do not become properties of window.

// ES module
const apiUrl = 'https://api.example.com'
// window.apiUrl → undefined

Back to index

6. Creation and execution phases

Every execution context — global or function — goes through two phases.

Phase 1: Creation

Before any statement runs, the engine:

1. Creates the variable and lexical environments
2. Sets up the scope chain (outer reference)
3. Determines this binding
4. Allocates memory for declarations

During creation:

console.log(typeof hoistedFn) // 'function'
console.log(typeof hoistedVar) // 'undefined'
 
hoistedFn() // works — function body is available
// console.log(hoistedLet) // ReferenceError — TDZ
 
var hoistedVar
function hoistedFn() {
  return 'I was hoisted'
}
let hoistedLet = 'not yet'

Interactive: creation vs execution

Phase 2: Execution

The engine runs code line by line:

• Assigns actual values to variables
• Executes expressions and function bodies
• Creates new function execution contexts on calls

var score = 10 // creation: score = undefined → execution: score = 10
 
function double(n) {
  return n * 2
}
 
var result = double(score) // FEC created → runs → returns 20
console.log(result) // 20

Back to index

7. Function execution context (FEC)

A Function Execution Context is created every time a function is invoked — not when it is defined.

function multiply(a, b) {
  const product = a * b
  return product
}
 
multiply(3, 4) // FEC #1 — arguments: a=3, b=4
multiply(5, 2) // FEC #2 — separate context, separate `product`

Each FEC gets:

• Its own argument object / parameter bindings
• A local variable environment
• Its own this binding (unless arrow function — inherits from enclosing lexical this)
• A link to the outer lexical environment (closure)

function createGreeter(prefix) {
  return function (name) {
    // FEC for this inner function links to createGreeter's environment
    return `${prefix}, ${name}!`
  }
}
 
const sayHi = createGreeter('Hi')
console.log(sayHi('Kazi')) // 'Hi, Kazi!'

Even after createGreeter returns and its FEC is popped off the stack, the inner function keeps a reference to prefix through the closure.

Back to index

8. The call stack

The call stack (execution context stack) is a LIFO structure that tracks which context is currently running.

┌─────────────────┐
│  innerFn() FEC  │  ← top (currently executing)
├─────────────────┤
│  outerFn() FEC  │
├─────────────────┤
│  GEC            │  ← bottom
└─────────────────┘

Rules:

• Push a new context when a function is called
• Pop a context when a function returns
• Only the top context executes at any moment

function a() {
  console.log('a start')
  b()
  console.log('a end')
}
 
function b() {
  console.log('b start')
  c()
  console.log('b end')
}
 
function c() {
  console.log('c')
}
 
a()

Output:

a start
b start
c
b end
a end

Stack timeline:

1. GEC runs → calls a() → push FEC for a
2. a calls b() → push FEC for b
3. b calls c() → push FEC for c
4. c returns → pop c
5. b returns → pop b
6. a returns → pop a

Interactive: call stack playground

Back to index

9. Stack vs heap memory

JavaScript uses two memory regions. Execution contexts and the call stack interact with both.

// Stack: primitive values and references
let count = 42 // number on stack
let active = true // boolean on stack
let ref = { id: 1 } // ref (address) on stack → object on heap
 
// Heap: the object `{ id: 1 }` lives here
ref.name = 'Kazi' // mutates heap object

function makeUser(name) {
  return { name, createdAt: Date.now() } // new heap object each call
}
 
const a = makeUser('Alice')
const b = makeUser('Bob')
// `a` and `b` are different heap objects; stack holds two separate references

Interactive: stack vs heap

Garbage collection

When no reference points to a heap object anymore, the engine's garbage collector reclaims that memory. Closures keep outer variables alive on the heap as long as the inner function is reachable.

function leakExample() {
  const huge = new Array(1_000_000).fill('data')
  return function () {
    return huge.length // `huge` stays on heap while this function exists
  }
}
 
const getter = leakExample()
// `huge` cannot be collected until `getter` is unreachable

Back to index

Conclusion

JavaScript execution context is the bridge between the code you write and how the engine actually runs it. Every script starts in a global context; every function call spins up a new one; the call stack keeps synchronous execution ordered; and lexical environments power scope and closures.

Key takeaways:

• Execution context = variable environment + lexical environment + this binding
• GEC is created once at startup; FEC is created on every function call
• Creation phase hoists declarations; execution phase assigns values and runs logic
• The call stack is LIFO — push on call, pop on return
• Stack holds primitives and frames; heap holds objects — closures keep heap data alive

The next time hoisting, closures, or this confuse you, ask: which execution context am I in, and what does its lexical environment look like? That question usually leads straight to the answer.

Have questions about execution context or closures? Reach out via the contact page.