How JS Works: The Execution Context

Concept

Everything in JavaScript happens inside an execution context. That one sentence is the whole lesson. When you run a file, the engine does not just start at line 1. It first builds a container — the execution context — and only then runs your code inside it. Every function you call gets its own container. Understanding what goes into that container, and in what order, is what makes hoisting, scope, closures and this easy to understand. (this is a keyword that points to an object. Lesson 5 explains it.)

Imagine the execution context as a box with two halves. The left half is a table of names and values. The right half is a pointer that walks through your code one line at a time. The engine always fills the left half completely before it starts walking the right half. That order is the source of almost every “why did JavaScript do that?” moment you will ever have. (The engine does not literally have a left and a right half. This is a picture to help you remember.)

Why this matters

You can write a lot of working JavaScript without knowing any of this. But the moment something surprises you — a variable that is undefined when you are sure you assigned it, a function that works when called “too early”, a counter inside a loop that prints the wrong number every time — the only real explanation is the execution context. Interviewers know this, which is why it is one of the most-asked fundamentals: it is a short question that shows whether you understand the language or only use it.

Every later lesson in this series builds directly on top of today: the call stack (Lesson 2) is a stack of execution contexts; hoisting (Lesson 3) is the result of the memory phase; scope (Lesson 7) is how one context can see the names of another; closures (Lesson 10) are a function keeping the variables of its context alive.

Key terms, explained simply

The two halves of an execution context

Here is the box. The left half is the memory component — the official name is variable environment. It stores every variable and function as a key → value pair. The right half is the code component — official name thread of execution. It executes your code one line at a time, top to bottom.

The two phases: memory first, then code

When the engine creates an execution context, it works in two strictly ordered phases.

1. Memory creation phase

   The engine reads through the code from top to bottom without running anything. For every var it finds, it reserves a slot in memory and puts the special placeholder undefined in it. (This is true for var. Lesson 3 shows that let and const are handled differently.) For every function declaration, it reserves a slot and stores the entire function body in it. When this phase ends, every name in your file already exists in memory.

2. Code execution phase

   Now the engine goes back to line 1 and runs the code for real. Each assignment replaces the undefined placeholder with the actual value. Each function call creates a brand-new execution context (with its own two phases) and pushes it on the call stack. When the last line finishes, the context is removed.

Traced example — step through it live

This is the program we will trace. It is deliberately tiny: one variable, one function, two calls. Read it once, guess what memory looks like after the memory phase, then step through the trace below and check your guess.

var n = 2;
function square(num) {
  var ans = num * num;
  return ans;
}
var square2 = square(n);
var square4 = square(4);

1var n = 2;
2function square(num) {
3  var ans = num * num;
4  return ans;
5}
6var square2 = square(n);
7var square4 = square(4);

Three things to notice in the trace:

• After the memory phase, before any code runs, n, square2 and square4 are all undefined, but square already holds the full function. Nothing has “executed” yet.
• Each call to square gets its own context with its own num and ans. In the second call, ans starts as undefined again. It remembers nothing from the first call.
• return does two jobs: it hands a value back, and it hands control back to the line that made the call. The function's context is deleted the moment that happens.

The call stack: how contexts are managed

You just watched contexts pile up and disappear. The structure that manages them is the call stack. A stack is a list where you only add and remove at the top, like a pile of plates. The call stack follows one simple rule: the context on top is the one currently running. The global context is pushed first and sits at the bottom the whole time. Every function invocation pushes a new context on top; every return pops it. When the program finishes, the global context is popped and the stack is empty.

This is why the global context is only ever destroyed at the very end, and why a function called inside a function inside a function produces three contexts stacked up, popped off in reverse order. Lesson 2 explains this in detail. For today, just remember the picture.

Synchronous, single-threaded — what that actually means

You will often hear “JavaScript is a synchronous, single-threaded language.” Now that you know the execution context, you can say exactly what it means:

• Single-threaded — a thread is one path of work that a program follows, one step at a time. JavaScript has one call stack, so it has one thread of execution. The engine can only be inside one context at a time.
• Synchronous — it means one step after another. Inside that thread, lines run in order. The engine does not move to the next line until the current one has finished. It never jumps ahead or runs two lines at once.

See it happen: Node and Chrome DevTools

Do not just trust the trace above. Watch the real engine do it. DevTools (short for developer tools) is the set of debugging panels built into Chrome. A debugger is a tool that lets you pause a running program and look inside it. A breakpoint is a marker on a line that tells the debugger to pause there. Save the example as index.js and use either method.

Method 1 — Chrome DevTools (recommended the first time)

1. Create a page that loads the file

   index.htmlCopy

   <!doctype html>
   <html>
     <body>
       <script src="index.js"></script>
     </body>
   </html>

2. Open it and set a breakpoint on line 1

   Open index.html in Chrome, press F12, go to the Sources tab, click index.js, and click the line number 1 to add a breakpoint. Reload the page. Execution pauses before line 1 runs.

3. Look at Scope while paused on line 1

   On the right, expand Scope → Global. You will see n: undefined, square2: undefined, square4: undefined and square: ƒ square(num). Nothing has executed and yet every name exists. That is the memory phase, live.

4. Step and watch the Call Stack panel

   Press Step (F9) repeatedly. Watch n become 2. When you step into square(n), a new entry square appears in the Call Stack panel above (anonymous) (the global context), and Scope → Local shows num and ans. When return runs, the entry disappears.

Method 2 — Node with the inspector

Prefer staying in the terminal? Run node inspect index.js. It starts paused on the first line. Type n to step to the next line, repl to open a prompt where you can type a name to see its value, and c to continue.

Predict the output

Before running it, write down what each of the three console.log lines prints. Then reason through the memory phase and the code phase.

console.log(a);
console.log(greet);
console.log(greet());

var a = 10;
function greet() {
  return "hello";
}

undefined
[Function: greet]
hello

Interview questions

These are the questions this lesson lets you answer. Try to answer each one out loud before opening it.

Practice before Lesson 2

1. Take the traced example and draw the execution contexts on paper — the global one and both square contexts — showing memory after phase 1 and after phase 2 for each. Compare against the stepper above.
2. Run Method 1 in Chrome and take a screenshot of the Scope panel while paused on line 1. Look at it until it feels obvious that nothing has run yet.
3. Change var square2 = square(n); to call a function that itself calls square. Predict how many contexts stack up, then confirm it in the Call Stack panel.
4. Explain the memory phase and the code phase to someone in under one minute, without looking at this page. If nobody is there, say it out loud to yourself.

Conclusion

JavaScript does not run your file top to bottom. It first builds a global execution context, fills its memory with every variable (undefined) and every function (its full body), and only then runs the code one line at a time on a single thread. Every function call builds a brand-new context of its own, pushes it on the call stack, runs it, and throws it away on return. Remember this picture. The next thirteen lessons all add details to it.