DEV Community: Marsha Teo

The JavaScript Runtime: Fixing the Mental Model

Marsha Teo — Fri, 10 Apr 2026 20:36:36 +0000

This article is part of a series on the JavaScript event loop.

Most explanations of JavaScript's event loop start with:

JavaScript is single-threaded.

This statement is technically true but doesn't explain certain behaviors in JavaScript you may have noticed:

setTimeout doesn't interrupt loops after the timer has run out
setTimeout doesn't block (like sleep(1) in C)
A resolved Promise still runs after synchronous code
await pauses a function but doesn't freeze the page
Rendering sometimes wait

So we're left asking:

Why didn’t my timeout fire?
Why didn’t it interrupt my loop?
Why does await pause this but not everything?
Why does nothing ever 'cut in'?

In this series, we'll build the understanding needed to make JavaScript stop feeling magical.

Today's core claim is simple:

JavaScript executes synchronously inside a task, and nothing can interrupt that execution.

What Does "Synchronous" and "Asynchronous" Really Mean?

First, let's define 'synchronous' and 'asynchronous' precisely.

Synchronous execution refers to code that runs immediately, executing from top to bottom via the call stack. We will show that this cannot be interrupted in JavaScript.

By contrast, asynchronous code refers to code whose result is not available immediately. Some work is initiated now, but its continuation runs later. In practice, this almost always involves a callback - a function that is scheduled to execute in the future. In JavaScript, asynchronous code includes not only async/await but also other mechanisms like setTimeout, Promise, and requestAnimationFrame.

As this series will make clear, asynchronous mechanisms do not block nor interrupt the call stack. Instead, they arrange for something to run later via scheduling.

For now, let's test the claim directly:

Can asynchronous callbacks interrupt synchronous execution?

Running the Experiments

You can run all code snippets in this series by pasting them into the browser console.

While some examples work in Node.js, others rely on browser APIs (like rendering or requestAnimationFrame), so the browser is the most reliable environment.

Baseline Case: Pure Synchronous Execution

Let's start with a simple for loop:

console.log("sync start");

for (let i = 0; i < 1e9; i++) {}

console.log("sync end");

The code runs from top to bottom. The output is unsurprisingly:

sync start
sync end

Test 1: Can `setTimeout` Interrupt a Loop?

Let's introduce an asynchronous mechanism with setTimeout:

console.log("sync start");

// Schedule asynchronous callback with setTimeout
setTimeout(() => {
  console.log("timeout fired");
}, 0);

for (let i = 0; i < 1e9; i++) {}

console.log("sync end");

If setTimeout could interrupt, we would see:

sync start
timeout fired
sync end

But what actually happens is this:

sync start
sync end
timeout fired

The timer did not 'cut in': It waited until the loop finished running.

Test 2: Can Promises Interrupt?

Now let's try a Promise:

console.log("sync start");

// Schedule asynchronous callback with a Promise
Promise.resolve().then(() => {
  console.log("promise callback");
});

for (let i = 0; i < 1e9; i++) {}

console.log("sync end");

If Promises could interrupt execution, we would see:

sync start
promise callback
sync end

But the observed behavior is:

sync start
sync end
promise callback

Even a resolved Promise does not interrupt synchronous execution. Once JavaScript starts running, it runs to completion.

Destroying the Wrong Mental Models

It's easy to imagine JavaScript like this:

JavaScript is running, but timers or promises can interrupt it when they're ready

In other words, setTimeout fires when ready and Promise callbacks can cut in once resolved.

This resembles signal handlers in C where a signal can interrupt a running program, jump to the handler function and then resume execution afterward. That is pre-emptive behavior where execution can be paused at arbitrary instruction boundaries and control temporarily transferred elsewhere. JavaScript does not behave this way.

We may also hold the mental model that:

Timers or promises run JavaScript on another thread.

In this model, JavaScript runs concurrently in multiple threads: The script is running on one thread; Timers run in a background thread; Promises resolve in another (or the same) background thread. If that were true, we would see interleaved console output.

However, in both tests, there is no interruption nor interleaved output between sync start and sync end in the console. These tests force us to accept that JavaScript execution is not pre-emptive. When JavaScript starts executing a task, it continues until the call stack is empty. Only then can anything else run JavaScript. Asynchronous work waits and queues.

But Where Does Asynchronous Work Wait?

JavaScript's behavior makes more sense when you realize that when you run JavaScript in the browser, you are not just running a language. You are running two cooperating systems: the JavaScript Engine and the JavaScript Runtime Environment.

The engine (V8 in Chrome/Node, SpiderMonkey in Firefox, JavaScriptCore in Safari) parses and compiles code, manages memory and executes functions via the call stack. When we say "JavaScript runs", we are referring to the engine. It knows variables, functions and the call stack. It does not know timers, the DOM, HTTP requests nor rendering.

Everything else is handled by the runtime (the browser or Node). For instance, the runtime provides web APIs (setTimeout, fetch, DOM events). Importantly, it also performs the asynchronous work outside the engine and decides when JavaScript is allowed to run again. This is the missing link:

The engine executes. The runtime schedules.

Let's revisit our first experiment:

console.log("sync start");

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

for (let i = 0; i < 1e9; i++) {}

console.log("sync end");

While the loop is running, what is happening structurally?

┌───────────────────────────────┐  ┌───────────────────────────────┐
│         CALL STACK            │  │         TASK QUEUE            │
├───────────────────────────────┤  ├───────────────────────────────┤
│ for loop                      │  │ timeout callback (waiting)    │
│ global script                 │  |                               | 
└───────────────────────────────┘  └───────────────────────────────┘

The for loop occupies the call stack. Even after the timer has expired, its callback doesn't interrupt the call stack. Instead, it waits in a queue managed by the runtime. The engine cannot run it (nor anything new) because the call stack is not empty. More broadly, the runtime schedules what the engine executes while the engine just executes whatever gets placed on the stack.

Introducing Tasks

When the runtime grants permission for the engine to execute JavaScript, that moment is an entry point into execution. This entry point or permission to run JavaScript is called a task. Examples include the initial script execution and the setTimeout callback. Once a task starts, JavaScript runs synchronously. Asynchronous mechanisms do not interrupt a task but instead schedules future tasks.

No worries if this doesn't make complete sense yet. We will refine "task" in later articles. For now, this is enough.

What This Sets Up

From this article, we have established:

JavaScript runs synchronously inside a task
Nothing can interrupt that execution
Asynchronous mechanisms do not cut in - they schedule.

But if asynchronous callbacks don't interrupt running code, how and when are they allowed to run? What exactly is a 'task'? Where are these queues? Who decides what runs next?

This is the subject of the next article.

JavaScript Event Loop Series: Building the Event Loop Mental Model from Experiments

Marsha Teo — Fri, 10 Apr 2026 20:35:43 +0000

I wrote this series because JavaScript has many "asynchronous" mechanisms (await, setTimeout, Promise, requestAnimationFrame) that look similar but behave very differently.

At first, I assumed they were interchangeable but that assumption quickly broke when I started debugging:

Why setTimeout(..., 0) doesn’t "run immediately"
Why await pauses a function but doesn’t freeze the page
Why DOM updates sometimes don’t show up when you expect
Why some "async" code still blocks rendering

These behaviours only make sense with the right mental model. This series builds that model by experimenting with small code snippets.

The core idea is simple:

JavaScript runs to completion inside a task, and nothing interrupts it.

From there, we layer in:

macrotasks (what a task actually is),
microtasks (why Promises run first),
async/await (pausing a function without pausing JavaScript),
rendering (why the screen doesn’t update mid-turn),
requestAnimationFrame (the missing pre-render scheduling layer), and finally,
what this means for real UI code.

Who this is for

This series is for you if you’ve ever felt that JavaScript async behavior is:

predictable in practice, but unclear in theory
"working" … until it suddenly doesn’t
full of rules you remember, but don’t fully understand

You don’t need prior knowledge of the event loop. The goal is to build a mental model you can use to reason about behavior — not just memorize it.

How to read this series

Each article builds on the previous one. You can jump around, but the payoff is highest if you go in order.

If you want the core mental model quickly: read Articles 1–3
If you care about rendering and UI behavior: Articles 5–7 connect the model to what you see on screen
If you just want answers: each article is self-contained, but the full model only emerges across the series

The articles

Here’s how the model unfolds:

1) Before the Event Loop: What Actually Runs JavaScript

Why doesn’t setTimeout interrupt your code? This article breaks the illusion: JavaScript runs synchronously, and async APIs don’t interrupt. Instead, they schedule.

Read it here.

2) Macrotasks: What a Task Actually Is

If nothing can interrupt JavaScript, when does anything else run? This article reframes tasks as entry points into execution, not chunks of work.

Coming soon

3) Microtasks: Why Promises Run First

Why do Promises always run before setTimeout? This article reveals microtasks as mandatory continuations that must run before JavaScript moves on.

Coming soon

4) async / await: Pausing Functions Without Pausing the World

Does await pause your program or just your function? This article shows how await actually works.

Coming soon

5) Rendering Is a Browser Decision, Not a JavaScript One

You updated the DOM. So why didn’t the screen change? This article explains why rendering is not triggered by JavaScript, but gated by it.

Coming soon

6) requestAnimationFrame: The Missing Scheduling Layer

If rendering only happens at certain moments, how do you run code at the right time? This article introduces requestAnimationFrame as the missing scheduling layer.

Coming soon

7) What the Event Loop Means for Real UI Code

Why do UIs freeze, skip updates, or feel laggy? This article connects the event loop to real-world UI behavior and shows how to work with the browser, not against it.

Coming soon

The mental model

This is the model everything in this series builds toward:

The browser (runtime) starts a macrotask
JavaScript runs synchronously until the call stack is empty
The runtime drains all microtasks
The browser runs any requestAnimationFrame callbacks
Microtasks drain again (if any were queued during requestAnimationFrame)
Only then can rendering happen

Continue the Conversation

If you want to discuss edge cases, counterexamples, or how this interacts with real applications, I’m always happy to chat.

You can find more of my writing at https://marshateo.com.

DEV Community: Marsha Teo

The JavaScript Runtime: Fixing the Mental Model

What Does "Synchronous" and "Asynchronous" Really Mean?

Running the Experiments

Baseline Case: Pure Synchronous Execution

Test 1: Can setTimeout Interrupt a Loop?

Test 2: Can Promises Interrupt?

Destroying the Wrong Mental Models

But Where Does Asynchronous Work Wait?

Introducing Tasks

What This Sets Up

JavaScript Event Loop Series: Building the Event Loop Mental Model from Experiments

Who this is for

How to read this series

The articles

The mental model

Continue the Conversation

Test 1: Can `setTimeout` Interrupt a Loop?