The JavaScript runtime at a glance

The runtime map

Your JavaScript code never runs on its own. It always runs inside a program called a runtime. A browser is a runtime. Node.js is a runtime too. This lesson draws one map of a runtime, so you can see where each part of your code runs, and when.

A runtime has these parts:

• The engine reads your JavaScript and runs it.
• The host is the program around the engine, such as a browser or Node.js. It adds extras such as timers, the web page, files, and the network.
• The queues are waiting lines. A function that should run later waits in a queue.
• The event loop takes the next waiting function from a queue and gives it to the engine to run.

You have met some of these ideas before. The Engines, runtimes & hosts lesson showed that the engine and the host are two different programs. The Recursion lesson showed the call stack. The Objects & references lesson showed that two variables can point at one object. This lesson puts all of them on one map.

1const price = 3;2console.log(price * 2);3console.log(typeof setTimeout);

Line 1 makes a variable, price, that holds 3. Line 2 multiplies it by 2 and prints 6. The engine does that work, because numbers and * are part of the JavaScript language. Line 3 uses typeof, which tells you what kind of value something is. It prints function, because the host gave the page a function called setTimeout.

The rest of the lesson looks at each part of the runtime in turn, with its real name.

The engine is the part that understands JavaScript. Chrome uses an engine called V8. Firefox uses SpiderMonkey. Safari uses JavaScriptCore. The engine reads your code, makes values, does the math, calls functions, and looks after memory. Two places inside the engine matter for this map:

• The call stack is a list of the function calls that are running right now. The newest call sits on top, and the top call is the one that runs.
• The heap is the memory where objects and functions are kept. A variable does not hold the object itself. It holds a reference, which says where the object is.

The call stack works the same way. When one function calls another, the new call goes on top. The first function waits. It carries on only after the new call returns.

1function plate(label) {Run2  console.log("start " + label);3  garnish(label);4  console.log("finish " + label);5}6 7function garnish(label) {8  console.log("garnish " + label);9}10 11plate("tea");12console.log("ready");

The replay used no queue. A plain function call runs straight away, because the current line asked for it. Queues only matter for work that should run later.

Now look at memory. Objects are kept in the heap. A variable holds a reference to an object, not a copy of it. So two variables can refer to the same object.

1const chef = { name: "Mina", tickets: 1 };2const alias = chef;3alias.tickets = alias.tickets + 1;4console.log(chef.tickets);

The drawing above is a simple model, not a picture of real memory. Real engines lay out memory in more complex ways, and they clean up objects that no one uses any more. You don't need those details here. You only need one rule: both names point at the same object, so a change made through one name shows up through the other.

1const cart = { items: 1 };2const sameCart = cart;3sameCart.items = 2;4console.log(cart.items);5console.log(cart === sameCart);

Line 1 makes an object with items: 1 and stores a reference to it in cart. Line 2 copies that reference into sameCart. It does not make a new object. Line 3 changes items to 2 through sameCart. Line 4 prints 2, because cart points at the same object. Line 5 prints true, because === finds that both names refer to one object.

If you need a real, separate copy, use structuredClone(cart). It works for plain data such as numbers, strings, arrays, and plain objects.

The host is the program that the engine runs inside. The extras it adds are called APIs: named functions and objects your code can use. A browser's extras are called Web APIs.

• A browser lets your code use the web page, clicks and other events, timers, network requests, and saved data.
• Node.js lets your code use files, the running program, servers, and timers.

The table below compares the two hosts. Read each row as: "for this kind of job, a browser gives you this, and Node.js gives you that."

This split helps you avoid a common mistake: thinking that every name you can use is part of JavaScript itself.

• Array.prototype.map is part of the JavaScript language.
• document.querySelector is a Web API from the browser.
• fs.readFile is an API from Node.js.

The engine runs the JavaScript around those calls. The host does the extra work, such as finding an element or reading a file.

A callback is a function you hand to someone else to call later. When a timer ends, the host has a callback to run. But the engine may still be busy with other code, and the host can't interrupt it. So the callback waits in a queue, a waiting line where the first one in is the first one out. There are two queues to know:

• The task queue holds bigger pieces of work: timer callbacks, most click and key handlers, and messages. The script itself also runs as one task.
• The microtask queue holds small, urgent callbacks. They run as soon as the call stack is empty, before the next task.

A promise is an object that stands for a result that may arrive later. In this lesson, you only need one fact about promises: a function you pass to a promise's .then method waits in the microtask queue. The function queueMicrotask puts a callback straight into the same queue.

1console.log("start");2queueMicrotask(() => {3  console.log("first");4  queueMicrotask(() => console.log("second"));5});6setTimeout(() => console.log("timer"), 0);

Line 1 prints start while the script runs. Line 2 puts a callback in the microtask queue. Line 6 starts a timer, so its callback will wait in the task queue. When the script ends, the microtask runs. It prints first and queues one more microtask. That new microtask also runs before any task, so second prints before timer.

Microtasks run soon, which is useful. But if each microtask keeps adding another one, tasks never get a turn. Timers wait, and the page can't redraw. A later lesson covers promises, timers, and microtasks in depth. For now, keep one rule: first the code running now, then all microtasks, then one task.

The event loop is a routine the host repeats over and over. In a browser, one turn of the loop goes like this:

1. Run one task until the call stack is empty.
2. Run every callback in the microtask queue, until it is empty.
3. Redraw the page, if the browser is ready to.
4. Take the next task, and start again.

This short program shows all the parts working together:

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

It prints A, D, C, B. Lines 1 and 4 run straight away. Line 2 asks the host for a timer, whose callback will wait in the task queue. Line 3 puts a callback in the microtask queue.

In the playground, press Step model to move the program through the map one step at a time. Then press Run in this browser. It runs the same program for real, so you can check the model against your browser.

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

One thread, many helpers

A thread is one line of work that a computer runs step by step. People say "JavaScript is single-threaded". This means your page runs one piece of JavaScript at a time, on one call stack. Two of your functions never run at the same moment on that stack.

That is why a long piece of code freezes the page. While it runs, clicks, timers, and redraws all have to wait.

The host, though, has many helpers that work at the same time as your code:

• A browser has helpers for timers, the network, drawing the page, and events from the mouse and keyboard.
• Node.js uses the computer's operating system and a library called libuv. Some file and encryption work runs on extra libuv threads.

These helpers never run your JavaScript functions. When their work is done, they put a callback in a queue. Later, the engine runs that callback.

The runtime map helps whenever code seems to run in the wrong order. Ask the matching question:

• A log appears late? Ask which queue it waited in.
• Code works in the browser but fails in Node.js? Ask whether it used a Web API.
• A button stops responding? Ask what kept the call stack busy.

1function slowCount() {2  for (let i = 0; i < 1_000_000; i++) {3    // The call stack stays busy. Clicks and redraws wait.4  }5}6 7function chunkedCount(total) {8  let i = 0;9  function slice() {10    const end = Math.min(i + 10000, total);11    while (i < end) i++;12    if (i < total) setTimeout(slice, 0);13  }14  slice();15}

The first function, slowCount, counts to a million in one go. Like the freeze demo in Engines, runtimes & hosts, it keeps the call stack busy the whole time.

The second function, chunkedCount, splits the work into small pieces called chunks. The inner slice function counts 10,000 more, then uses setTimeout to run the next chunk as a new task. Between chunks, the call stack is empty, so the browser can handle clicks and redraw the page.

1let completed = 0;2function doSlice() {3  completed += 2;4  console.log(completed);5  if (completed < 4) setTimeout(doSlice, 0);6}7doSlice();

The first call to doSlice adds 2 and prints 2. Because completed is still below 4, it schedules itself again with setTimeout. The second run, as a later task, prints 4 and stops. Chunks keep the page responsive. They don't make the total work smaller, and very tiny chunks add extra waiting between them.

Common misconceptions

• "A zero timer runs right now." Zero only means "don't add a delay". The callback still waits as a later task.
• "Microtasks can run in the middle of a function." They wait until the call stack is empty.
• "Promises use extra threads." A .then callback runs as a microtask, on the same thread as the rest of your JavaScript.
• "The web page is part of JavaScript." The page, through document, is a Web API from the browser.
• "The heap drawing shows real memory." It is a simple model that explains references.

The table below pairs each wrong idea with what really happens. Read each row from left to right.

Key takeaways

• The engine runs the JavaScript language. It keeps the call stack, and it keeps objects in the heap.
• The host adds extras: the web page, timers, and fetch in a browser, or files and process in Node.js.
• A plain function call runs right away. Timer and click callbacks wait as tasks. .then callbacks wait as microtasks.
• The event loop waits for an empty call stack, runs every microtask, then starts the next task.
• Your JavaScript runs one piece at a time, but the host has helpers that work at the same time.

A JavaScript runtime is an engine plus a host. The engine runs one piece of JavaScript at a time and keeps objects in memory. The host adds extras, keeps callbacks waiting in queues, and uses the event loop to run each one when the call stack is free.

Up next: Execution contexts.