0 to 1: How JavaScript Works Under the Hood

A deep dive into JavaScript’s internal mechanics, exploring the execution context, call stack, memory management, event loop, and the role of the JavaScript engine in transforming code into interactive experiences.

While many developers can write functional JavaScript code, truly mastering the language requires understanding what happens after you hit “run.” This journey from 0 to 1 explores the hidden machinery—the JavaScript engine, runtime, and core concepts that power every line of code you write.

The JavaScript Engine: The Interpreter and Optimizer

When you execute JavaScript, you’re not talking directly to the computer’s hardware. Instead, your code is processed by a JavaScript Engine. Prominent examples include Google’s V8 (Chrome, Node.js), SpiderMonkey (Firefox), and JavaScriptCore (Safari). These engines are complex programs that perform several critical steps:

1. Parsing: The engine first reads your source code and breaks it down into tokens. It then generates an Abstract Syntax Tree (AST)—a hierarchical tree structure that represents the grammatical composition of your program.

2. Compilation and Execution: The myth that JavaScript is purely an “interpreted” language is outdated. Modern engines use Just-In-Time (JIT) Compilation. The AST is converted into bytecode. As the code runs, the engine’s monitor (or “profiler”) watches for “hot” code paths—sections that are executed frequently. These hot paths are then compiled down to highly optimized machine code by the optimizing compiler (like V8’s TurboFan), making subsequent executions incredibly fast. If the profiler’s assumptions become invalid (e.g., a variable changes type), the optimized code is “deoptimized” and falls back to a less optimized version or the interpreter.

The Execution Context and the Call Stack

As the engine executes code, it manages execution using Execution Contexts. Think of an execution context as an environment where a piece of code is evaluated. The first context created is the Global Execution Context.

Each execution context has two phases:

• Creation Phase: The engine sets up memory space for variables and functions (“Hoisting”). Variables are initially set to undefined, while function declarations are stored in their entirety.
• Execution Phase: The code is executed line-by-line, assigning values to variables and invoking functions.

When a function is invoked, a new Function Execution Context is created. This is managed using the Call Stack, a LIFO (Last-In, First-Out) data structure. The engine pushes the new context onto the stack when a function is called and pops it off when the function returns. The call stack is what enables JavaScript’s synchronous, single-threaded nature.

function first() {
    console.log("Inside first");
    second(); // Call `second`
    console.log("Back to first");
}

function second() {
    console.log("Inside second"); // This executes after `first` is pushed but before it finishes
}

first(); // Initial call
// Call Stack order:
// 1. `first` is pushed -> logs "Inside first"
// 2. `second` is pushed on top of `first` -> logs "Inside second"
// 3. `second` is popped
// 4. `first` continues -> logs "Back to first"
// 5. `first` is popped

Memory Heap: Where Things Are Stored

The Memory Heap is a large, mostly unstructured region of memory where dynamic memory allocation happens. This is where objects, functions, and other complex data types are stored. The JavaScript engine automatically allocates memory here when you create an object and employs a Garbage Collector (like V8’s Orinoco) to automatically free up memory that is no longer reachable or needed, preventing memory leaks.

The Concurrency Model and Event Loop

This is perhaps the most crucial concept for understanding JavaScript’s behavior. JavaScript has a single-threaded runtime, meaning it can only execute one command at a time. So, how does it handle asynchronous operations like fetching data or setting timers without blocking the main thread? The answer lies in the Concurrency Model based on an Event Loop.

The key components are:

1. Call Stack: (As described above) Where your synchronous code runs.
2. Web APIs: Provided by the browser (or the Node.js runtime for C++ APIs). Functions like setTimeout, fetch, and DOM events are not part of the JavaScript engine itself. When called, they are handed off to these APIs.
3. Callback Queue (or Task Queue): Once an asynchronous Web API operation completes, its callback function is placed into this queue.
4. Event Loop: The event loop has one simple job: constantly check if the Call Stack is empty. If it is, it takes the first callback from the Callback Queue and pushes it onto the Call Stack for execution.

console.log("Start");

setTimeout(function cb() {
    console.log("Callback from setTimeout");
}, 0);

console.log("End");

// Output:
// "Start"
// "End"
// "Callback from setTimeout"

Explanation:

• "Start" is logged, and the console.log call is popped from the stack.
• setTimeout is called. Its cb callback is registered with the Web API, which starts the timer (of 0ms).
• The setTimeout function itself finishes, and it’s popped from the stack.
• "End" is logged, and its call is popped.
• The Call Stack is now empty.
• The Web API, seeing the timer has expired, pushes the cb callback into the Callback Queue.
• The Event Loop sees the empty Call Stack and a callback waiting in the queue. It moves cb to the Call Stack.
• cb executes, logging "Callback from setTimeout".

There’s also a Microtask Queue (for Promises and MutationObserver) which has a higher priority than the Callback Queue. The Event Loop will process all microtasks before moving on to any task in the Callback Queue.

Conclusion

Going from 0 to 1 in understanding JavaScript means looking past the syntax and seeing the intricate system beneath. The engine’s JIT compilation, the structured management of execution contexts via the call stack, and the non-blocking nature enabled by the event loop together form the powerful, responsive, and sometimes surprising behavior of JavaScript. Grasping these underlying principles is what separates proficient coders from true JavaScript experts, enabling them to write more efficient, predictable, and performant applications.