What is the difference between the JavaScript engine and runtime?

The engine (V8, SpiderMonkey) parses, compiles, and executes JavaScript. The runtime is the full environment: engine + call stack + memory heap + Web APIs + callback/microtask queues + event loop. The engine lives inside the runtime.

Why do Promises run before setTimeout?

Promise.then callbacks go to the microtask queue, which has higher priority than the callback (macrotask) queue where setTimeout callbacks land. The event loop drains all microtasks before processing the next macrotask.

What is non-blocking I/O in JavaScript?

Async operations like fetch and setTimeout are handled by Web APIs on background threads. The main JS thread continues executing. When complete, callbacks are queued and the event loop picks them up when the call stack is empty.

How do Web Workers relate to single-threaded JavaScript?

JavaScript's main thread is single-threaded, but Web Workers run JS in separate threads for CPU-heavy work. They cannot access the DOM but communicate via postMessage, keeping the main thread responsive.

JavaScript Internals

Event loop, call stack, V8, and memory — the foundation every SDE-2 frontend interview tests.

Module 7 · JavaScript Internals

How JavaScript actually runs: V8 engine, call stack, memory heap, Web APIs, event loop, microtask vs callback queues, non-blocking I/O, garbage collection, and Web Workers.

JavaScript runtime environment: V8 engine, call stack, memory heap, Web APIs, event loop, microtask vs callback queues, non-blocking I/O, V8 optimization, garbage collection, and Web Workers — the foundation of every async interview question.

About this module

JavaScript Internals is the foundation of every SDE-2 frontend interview — if you understand the runtime, event loop, and memory model, async bugs, performance issues, and polyfill questions become predictable.

This module walks through the full runtime environment with step-by-step examples: call stack traces, microtask vs macrotask ordering, debounce/throttle internals, V8 optimization, GC, and Web Workers.

Mastering this module means you can predict async output in whiteboard questions, explain why the UI freezes during heavy synchronous work, and describe how the browser keeps I/O non-blocking despite JavaScript being single-threaded.

Covers the runtime vs engine split, call stack overflow, microtask priority over macrotasks, Promises and async/await ordering, closure memory, V8 hidden classes, mark-and-sweep GC, and moving heavy work off-thread with Web Workers.

Why this matters

Event loop questions appear in nearly every SDE-2 frontend loop. Understanding runtime internals explains Promise ordering, why setTimeout(fn, 0) isn't instant, how debounce works, and how to debug memory leaks and UI freezes. This module connects browser APIs to the single-threaded JavaScript model.

Key topics covered

JavaScript Runtime
V8 Engine
Call Stack
Memory Heap
Web APIs
Event Loop
Microtask Queue
Callback Queue
Non-Blocking I/O
V8 Optimization
Garbage Collection
Web Workers
Debounce and Throttle

Where you'll use it

Predicting console.log output order in async code interviews
Implementing debounce/throttle with setTimeout internals
Debugging UI freezes from blocking the main thread
Offloading CPU-heavy work to Web Workers
Explaining microtask vs macrotask priority on a whiteboard

What Is the JavaScript Runtime?

The full environment that executes your code — not just the engine.

The JavaScript Runtime is the environment that runs JavaScript. Think of it as a house: the engine is the furnace, but the house also needs plumbing (Web APIs), storage (memory heap), a to-do list (queues), and a manager (event loop).

JavaScript Engine

V8 — parse, compile, execute

Call Stack

LIFO — which function is running

Memory Heap

Objects, arrays, closures

Web APIs

setTimeout, fetch, DOM

Microtask Queue

Promises, queueMicrotask

Callback Queue

setTimeout, events, I/O

Event Loop

Routes tasks → call stack

JavaScript Runtime
├─ JavaScript Engine (V8, SpiderMonkey)
├─ Call Stack
├─ Memory Heap
├─ Web APIs (Browser)
├─ Callback Queue
├─ Microtask Queue
└─ Event Loop

Interview one-liner

Runtime = Engine + Call Stack + Memory Heap + Web APIs + Callback Queue + Microtask Queue + Event Loop.

JavaScript Engine — Deep Dive

Parses, compiles, executes — V8, SpiderMonkey, JavaScriptCore.

•Parses, compiles, and executes JavaScript code
•Manages memory — heap + stack
•Runs garbage collection

Engine	Browser / Runtime
V8	Chrome, Node.js, Deno, Edge
SpiderMonkey	Firefox
JavaScriptCore (JSC)	Safari
Chakra	Edge (legacy)

V8 Engine Pipeline

V8 Engine Pipeline
├─ Parser (Source Code → AST)
├─ Ignition (AST → Bytecode, fast startup)
├─ TurboFan (Bytecode → Optimized native code)
└─ Garbage Collector (generational memory management)

Ignition vs TurboFan

Ignition interprets bytecode quickly on startup. TurboFan optimizes hot code paths into fast native machine code. If types change at runtime, V8 deoptimizes back to bytecode.

Aspect	JavaScript Engine	JavaScript Runtime
What	Compiler/parser only	Full execution environment
Examples	V8, SpiderMonkey	Browser, Node.js, Deno
Contains	Parser, compiler, optimizer, GC	Engine + stack + heap + APIs + queues
Analogy	Car engine	Entire car

Call Stack

LIFO stack tracking which function is currently executing.

The call stack is a stack data structure (Last-In, First-Out). Only one function runs at a time — JavaScript is single-threaded. When a function is called, it's pushed; when it returns, it's popped.

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 — done");
}

a();

Output

a start
b start
c — done
b end
a end

Call stack flow

a() pushed → [a]
b() pushed → [a, b]
c() pushed → [a, b, c]
c() done → [a, b]
b() done → [a]
a() done → []

Stack overflow

Infinite recursion fills the call stack until RangeError: Maximum call stack size exceeded.

Memory Stack vs Memory Heap

Where primitives and objects live in memory.

Aspect	Memory Stack	Memory Heap
Stores	Primitives, references	Objects, functions, arrays, closures
Size	Static (fixed per frame)	Dynamic (grows at runtime)
Access	Fast	Slower lookup
Allocation	Automatic on function call	Manual via new / literals

// Stack: primitive values + references
let count = 42;           // number on stack
let name = "Ada";         // string reference on stack

// Heap: the actual object
const user = { id: 1, name: "Ada" };  // object on heap
const nums = [1, 2, 3];               // array on heap

Closures live on the heap

When a function closes over variables, those bindings are stored on the heap — which is why closures can cause memory leaks if references aren't released.

Web APIs

Browser-provided async capabilities — not part of the JS language.

Web APIs are provided by the browser (or Node.js libuv in Node) — not the JavaScript engine. They look like JavaScript functions but run on separate threads. When done, they push callbacks into queues.

•setTimeout() / setInterval() — timer thread
•fetch() / XMLHttpRequest — network thread
•DOM API — document.getElementById, addEventListener
•localStorage / sessionStorage
•console.log — browser-provided

Key point

Web APIs run in the browser's thread — not the JavaScript engine thread. They are facade functions that look like JS but aren't part of the language spec.

console.log("1 — sync, call stack");

setTimeout(() => {
  console.log("3 — callback queue (via Web API timer)");
}, 0);

console.log("2 — sync, call stack");

Output

1 — sync, call stack
2 — sync, call stack
3 — callback queue (via Web API timer)

setTimeout(fn, 0) is not instant

The timer is handled by a Web API. The callback waits in the callback queue until the call stack is empty and all microtasks are drained.

The Event Loop

The coordinator between queues and the call stack.

The event loop continuously checks: is the call stack empty? If yes, drain all microtasks, then run one macrotask. Repeat. It never interrupts running synchronous code.

1. Run synchronous code (call stack)

2. Call stack empty?

3. Drain ALL microtasks (FIFO)

4. Run ONE macrotask (FIFO)

5. Browser render (if needed)

6. Repeat from step 2

Interactive · Event loop demo

console.log("1");
setTimeout(() => console.log("4"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("2");

Idle

Call stack

empty

Microtask queue

empty

Macrotask queue

empty

Console output

—

while (running) {
  // 1. If call stack not empty → keep executing
  // 2. If call stack empty:
  //    a. Execute ALL microtasks (FIFO)
  //    b. Execute ONE callback (FIFO)
  //    c. Repeat
}

•Never executes while call stack has items
•Executes ALL microtasks before any callback
•Executes ONE callback at a time (even if queue has many)

Golden rule

Microtasks always beat macrotasks. Promise.then runs before setTimeout, even setTimeout(fn, 0).

Microtask Queue vs Callback Queue

Two queues, different priorities — this is the #1 interview topic.

Callback Queue (Task Queue)

Holds callback functions ready to execute. FIFO. Handles setTimeout, setInterval, I/O, DOM events. Lower priority than microtasks.

setTimeout(() => {
  console.log("timeout callback");
}, 0);

•setTimeout called → Web API handles timer
•Timer completes → callback pushed to Callback Queue
•Event loop → when stack empty, push callback to stack
•Callback executes

Microtask Queue

Higher priority than Callback Queue. Handles Promises, queueMicrotask(), MutationObserver.

console.log("start");
setTimeout(() => console.log("timeout"), 0);
Promise.resolve().then(() => console.log("promise"));
console.log("end");

Output

start
end
promise  ← microtask (runs first)
timeout  ← callback (runs after)

Aspect	Microtask Queue	Callback Queue (Macrotask)
Priority	Higher	Lower
Executes per tick	All pending microtasks	Exactly one task
FIFO	Yes	Yes
Sources	Promise.then, queueMicrotask, MutationObserver	setTimeout, setInterval, I/O, DOM events
Runs when	After sync code, before macrotasks	After all microtasks drained

Memory trick

Microtasks = Promises (high priority). Callbacks = setTimeout (low priority).

Output Ordering — Worked Examples

Step through these until the pattern is automatic.

Example 1 — Classic interview question

console.log("A");
setTimeout(() => console.log("B"), 0);
Promise.resolve().then(() => console.log("C"));
console.log("D");

Output

A
D
C  ← microtask (Promise)
B  ← macrotask (setTimeout)

Step-by-step execution

console.log('A') → call stack → Output: A
setTimeout() → Web API → timer starts
Promise.resolve() → microtask queued → [C]
console.log('D') → call stack → Output: D
Call stack empty → drain microtasks → Output: C
Callback queue → run one macrotask → Output: B

Sync first (A, D). Stack empty → all microtasks (C). Then one macrotask (B).

Example 2 — queueMicrotask + nested microtasks

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
queueMicrotask(() => console.log("4"));
console.log("5");

Output

1
5
4  ← queueMicrotask (FIFO among microtasks)
3  ← Promise.then
2  ← setTimeout

Example 3 — Microtask inside macrotask

console.log("start");

setTimeout(() => {
  console.log("timeout");
  Promise.resolve().then(() => console.log("promise inside timeout"));
}, 0);

Promise.resolve().then(() => console.log("promise"));

console.log("end");

Output

start
end
promise
timeout
promise inside timeout  ← microtask drains after its macrotask

Complete Execution Flow

From source code to event loop — the full pipeline.

1. Source Code

2. Parser → AST

3. Compiler → Bytecode

4. Interpreter (Ignition) → Call Stack

5. Execution → Memory Heap (variables, objects)

6. Async operations → Web APIs

7. Callbacks / Microtasks → Queues

8. Event Loop → check queues when stack empty

9. Push to Call Stack → Execute

Interview tip

Walk through this pipeline when asked "what happens when JavaScript runs?" Start with parsing, end with the event loop picking up async callbacks.

Non-Blocking I/O

Async work happens off the main thread — the event loop picks up results.

When you call fetch(url), the network request runs in a Web API thread. JavaScript continues immediately. When the response arrives, the callback enters the queue and the event loop runs it when the stack is free.

console.log("Request sent");

fetch("/api/users")
  .then((res) => res.json())
  .then((users) => console.log("Got users:", users.length));

console.log("UI still responsive");

Output

Request sent
UI still responsive
Got users: 42  ← later, when network completes

Asynchronicity in JavaScript

How single-threaded JS handles async without blocking.

JavaScript handles async via four cooperating pieces: the event loop manages scheduling, the callback queue holds macrotasks, the microtask queue holds promise callbacks, and Web APIs run async work off the main thread.

•Event Loop — middleman between queues and call stack
•Callback Queue — setTimeout, events, I/O (low priority)
•Microtask Queue — Promises, queueMicrotask (high priority)
•Web APIs — async operations in browser threads

Component	Purpose	Priority	FIFO / LIFO
Call Stack	Track running functions	Highest	LIFO
Microtask Queue	Promises, queueMicrotask	High	FIFO
Callback Queue	setTimeout, events, I/O	Low	FIFO
Event Loop	Manage queues → stack	N/A	N/A
Web APIs	Async operations	N/A	N/A
Memory Heap	Objects, functions	N/A	N/A
Memory Stack	Primitives	N/A	N/A

Why JavaScript Is Single-Threaded

Pros, cons, and the Web Worker escape hatch.

	Detail
Why	Simpler design, no race conditions on DOM, easier to implement
Pros	No thread locks, no synchronization bugs, easier debugging
Cons	CPU-heavy work blocks UI, no parallel computation on main thread
Solution	Async I/O via event loop + Web Workers for parallel CPU work

Blocking example

A synchronous loop for 5 seconds freezes the entire page. Async patterns and Workers exist specifically to avoid this.

V8 Optimization Pipeline

How Chrome and Node.js compile JavaScript for speed.

Source code

Parser → AST

Ignition → Bytecode

TurboFan → Optimized machine code

Garbage Collector (generational)

•Inline caching — reuse hidden class lookups
•Function inlining — reduce call overhead
•Escape analysis — stack-allocate where possible
•Deoptimization — fall back to bytecode if types change at runtime

Garbage Collection

Automatic memory management in V8.

•Generational GC — young (new) vs old (survived) object spaces
•Scavenger — fast collection for young generation
•Mark-and-sweep — mark reachable objects, free unreachable
•Incremental GC — small cycles to avoid long main-thread pauses

Common leak sources

Detached DOM nodes, uncleared timers, closures holding large references, accidental global variables.

Web Workers

True parallel JavaScript — separate thread, no DOM access.

// main.js
const worker = new Worker("worker.js");

worker.postMessage({ numbers: [1, 2, 3, 4, 5] });

worker.onmessage = (event) => {
  console.log("Result from worker:", event.data);
};

// worker.js
self.onmessage = (event) => {
  const sum = event.data.numbers.reduce((a, b) => a + b, 0);
  self.postMessage(sum);
};

•Runs on a separate thread — does not block main thread
•Cannot access DOM or window
•Communicate via postMessage / onmessage
•Use for: image processing, parsing large JSON, crypto, sorting

Key Interview Takeaways

Ten points to nail the JavaScript runtime question.

•JavaScript Runtime = environment executing JS (engine + surroundings)
•Engine = V8 (Chrome/Node), SpiderMonkey (Firefox) — parses, compiles, executes
•Call Stack = LIFO, single-threaded, tracks running functions
•Memory Heap = objects/functions (dynamic). Memory Stack = primitives (static)
•Web APIs = setTimeout, fetch, DOM — browser-provided, not native JS
•Callback Queue = setTimeout callbacks, FIFO, low priority
•Microtask Queue = Promises, FIFO, high priority — runs before callbacks
•Event Loop = middleman; drains all microtasks, then one callback at a time
•Single-threaded = one call stack, no parallel execution on main thread
•Non-blocking I/O = async in background, event loop manages completion

Frequently Asked Questions

Common interview questions about JavaScript internals.

Engine

Browser / Runtime

Chrome, Node.js, Deno, Edge

SpiderMonkey

Firefox

JavaScriptCore (JSC)

Safari

Chakra

Edge (legacy)

V8 Engine Pipeline ├─ Parser (Source Code → AST) ├─ Ignition (AST → Bytecode, fast startup) ├─ TurboFan (Bytecode → Optimized native code) └─ Garbage Collector (generational memory management)

Aspect

JavaScript Engine

JavaScript Runtime

What

Compiler/parser only

Full execution environment

Examples

V8, SpiderMonkey

Browser, Node.js, Deno

Contains

Parser, compiler, optimizer, GC

Engine + stack + heap + APIs + queues

Analogy

Car engine

Entire car

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 — done"); } a();

Aspect

Memory Stack

Memory Heap

Stores

Primitives, references

Objects, functions, arrays, closures

Size

Static (fixed per frame)

Dynamic (grows at runtime)

Access

Fast

Slower lookup

Allocation

Automatic on function call

Manual via new / literals

// Stack: primitive values + references let count = 42; // number on stack let name = "Ada"; // string reference on stack // Heap: the actual object const user = { id: 1, name: "Ada" }; // object on heap const nums = [1, 2, 3]; // array on heap

Aspect

Microtask Queue

Callback Queue (Macrotask)

Priority

Higher

Lower

Executes per tick

All pending microtasks

Exactly one task

FIFO

Yes

Sources

Promise.then, queueMicrotask, MutationObserver

setTimeout, setInterval, I/O, DOM events

Runs when

After sync code, before macrotasks

After all microtasks drained

console.log("start"); setTimeout(() => { console.log("timeout"); Promise.resolve().then(() => console.log("promise inside timeout")); }, 0); Promise.resolve().then(() => console.log("promise")); console.log("end");

Component

Purpose

Priority

FIFO / LIFO

Call Stack

Track running functions

Highest

LIFO

Microtask Queue

Promises, queueMicrotask

High

FIFO

Callback Queue

setTimeout, events, I/O

Low

FIFO

Event Loop

Manage queues → stack

N/A

Web APIs

Async operations

N/A

Memory Heap

Objects, functions

N/A

Memory Stack

Primitives

N/A

Detail

Why

Simpler design, no race conditions on DOM, easier to implement

Pros

No thread locks, no synchronization bugs, easier debugging

Cons

CPU-heavy work blocks UI, no parallel computation on main thread

Solution

Async I/O via event loop + Web Workers for parallel CPU work

// main.js const worker = new Worker("worker.js"); worker.postMessage({ numbers: [1, 2, 3, 4, 5] }); worker.onmessage = (event) => { console.log("Result from worker:", event.data); }; // worker.js self.onmessage = (event) => { const sum = event.data.numbers.reduce((a, b) => a + b, 0); self.postMessage(sum); };

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

What Is the JavaScript Runtime?

JavaScript Engine — Deep Dive

Call Stack

Memory Stack vs Memory Heap

Web APIs

The Event Loop

Microtask Queue vs Callback Queue

Output Ordering — Worked Examples

Complete Execution Flow

Non-Blocking I/O

Asynchronicity in JavaScript

Why JavaScript Is Single-Threaded

V8 Optimization Pipeline

Garbage Collection

Web Workers

Key Interview Takeaways

Frequently Asked Questions

About this chapter

About this module

Why this matters

Key topics covered

Where you'll use it

What Is the JavaScript Runtime?

JavaScript Engine — Deep Dive

Call Stack

Memory Stack vs Memory Heap

Web APIs

The Event Loop

Microtask Queue vs Callback Queue

Output Ordering — Worked Examples

Complete Execution Flow

Non-Blocking I/O

Asynchronicity in JavaScript

Why JavaScript Is Single-Threaded

V8 Optimization Pipeline

Garbage Collection

Web Workers

Key Interview Takeaways

Frequently Asked Questions