DEV Community: Marsha Teo

Rendering Is a Browser Decision, Not a JavaScript One

Marsha Teo — Thu, 30 Apr 2026 17:37:14 +0000

This is the fifth article in a series on how JavaScript actually runs. You can read the full series here or on my website.

You change the DOM.

You expect the screen to update.

It doesn’t.

Why?

In the earlier articles, we established three constraints:

JavaScript runs to completion.
Tasks form scheduling boundaries.
Microtasks must fully drain before moving on.

Now we add a fourth:

The browser will not render while a macrotask is running nor while microtasks are draining.

Rendering Is a Browser Decision

Up to this point in the series, we’ve focused on two pieces of the system:

The JavaScript engine, which executes code and manages the call stack.
The runtime, which provides the event loop and scheduling rules.

But neither of these is responsible for rendering.

Beyond the JavaScript engine and the runtime, the browser also contains a rendering engine — the subsystem responsible for layout and painting.

The engine executes your code. The runtime manages when that code runs. The rendering engine decides when the result becomes visible.

For simplicity, this article will refer to that rendering engine simply as the browser.

The Rendering Misconception

When I first started learning JavaScript, I carried several mental models that felt reasonable:

DOM updates render immediately
If I change the UI, the user will see it right away.
The browser renders continuously at 60fps.

These felt natural because the screen often updates quickly. But they're incomplete: Rendering does not happen whenever the DOM changes. Instead, rendering happens only when there is a 'safe opportunity', after the current macrotask finishes and the microtask queue is empty.

Rendering is not triggered by DOM mutation. It is gated by scheduling boundaries. Let’s test that.

Running the Experiments

These experiments rely on the browser’s rendering behaviour.

Create a simple HTML file with the following content:

   <div id="box">Initial</div>

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

These examples will not work in Node.js because they depend on the DOM and browser rendering.

Test 1: DOM Updates Inside One Macrotask

What happens when we have multiple DOM updates within the same macrotask? We may write something like the following, using a placeholder before the final string is ready:

const box = document.getElementById("box");

box.textContent = "Temporary string";

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

box.textContent = "Final string of Test 1";

We might worry that "Temporary string" would briefly appear before "Final string" is ready. But that doesn't happen. Phew!

Both updates occur inside the same macrotask and the browser refuses to render mid-task. It waits until the entire macrotask is finished, checks that there is no microtask in the queue and finally considers rendering.

The intermediate DOM states never show.

Test 2: Microtasks Also Delay Rendering

What if the second update happens in a microtask instead? Would "Temporary string" appear briefly?

const box = document.getElementById("box");

box.textContent = "Temporary string";

Promise.resolve().then(() => {
  box.textContent = "Final string of Test 2";
});

Again, we only see "Final string of Test 2".

The initial macrotask runs and sets "Temporary string". After the call stack is empty, the microtask runs immediately after to update the DOM to "Final string". Only now does the browser get an opportunity to render.

Microtasks delay rendering just like synchronous code does.

Test 3: Breaking Into a New Task Allows Paint

Now consider a timer callback:

const box = document.getElementById("box");

box.textContent = "Temporary string";

setTimeout(() => {
  box.textContent = "Final string of Test 3";
}, 1000);

This time we may see "Temporary string", followed by "Final string of Test 3" a second later.

Unlike the previous tests, we have now introduced a task boundary. The browser finishes the initial macrotask, drains microtasks (there are none here) and gets an opportunity to render. If it chooses to render, "Temporary string" becomes visible.

Later, when the runtime schedules the timer's macrotask, the DOM updates to "Final string" and the next render will reflect this.

Rendering is allowed at task boundaries. This does not mean that rendering is guaranteed between macrotasks; only that it can only happen there.

Why Rendering Waits

If the browser could render in the middle of a macrotask or in the middle of microtask draining, it could display half-updated DOM, inconsistent layout and/or partially computed state.

Thankfully, with this constraint, the browser renders only stable states, where a macrotask has finished and the microtask queue is empty. There would be no partial work in progress and hence rendering is atomic with respect to JavaScript execution.

The Correct Mental Model

With these tests, we've shown that the browser does not render whenever the DOM changes. Instead:

The browser renders only after JavaScript finishes its turn.

Here, a "turn" means the current macrotask completes and the microtask queue has been fully drained.

Rendering is allowed only at those boundaries. This does not mean the browser renders after every turn, only that it cannot render during one. The rendering decision is gated by the same scheduling rules we’ve been building throughout this series.

What This Prepares Us For Next

If rendering only happens at specific boundaries, a new question emerges: How do we write code that runs at the right moment?

setTimeout creates a new macrotask but it does not align with the browser's frame timing. Microtasks delay rendering but they do not schedule it. If we want smooth animation and responsive updates, we need a way to run code just before the browser renders the next frame.

This is what requestAnimationFrame is design for. In the next article, we'll look more closely at how the browser's rendering cycle works and how to schedule work in harmony with it.

This article was originally published on my website.

async / await: Pausing a Function Without Pausing JavaScript

Marsha Teo — Mon, 27 Apr 2026 06:35:28 +0000

This is the fourth article in a series on how JavaScript actually runs. You can read the full series here or on my website.

In the last article, we established a precise rule:

Once a macrotask finishes, JavaScript drains all microtasks before selecting the next macrotask.

Microtasks like Promises are continuations that must complete before the runtime moves on to the next macrotask. async/await is often described as syntactic sugar over Promises. If that's the case, we should already understand how await works.

Let’s see.

The Possible Mental Models

Before we look at any code, consider this question: When JavaScript reaches await, what actually happens?

It's surprisingly easy to carry one of the following mental models (I certainly did when I first started learning JavaScript). Which of these feel right?

a. await blocks the entire program before the value resolves, like sleep() in C or C++
b. await pauses the function and immediately yields to the event loop, creating a new macrotask
c. await splits the function and schedules the remainder as a microtask

Pause for a moment. Pick one and we'll test it.

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.

Test for Mental Model A (`await` Blocks)

Let's see if await pauses the entire program:

async function test() {
  console.log("Inside test");
  await Promise.resolve();
  console.log("After await");
}

console.log("Before test");
test();
console.log("After test");

If await blocked the program, we would expect:

Before test
Inside test
After await
After test

Instead, we observe that After test runs before After await:

Before test
Inside test
After test
After await

It appears that await does not block JavaScript. Execution continues after calling test(). So whatever await does, it does not stop everything.

Test for Mental Model B (`await` Yields)

Perhaps await pauses the function and immediately hands control back to the runtime for it to choose another macrotask:

async function test() {
  console.log("Inside test");
  await Promise.resolve();
  console.log("After await");
}

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

console.log("Before test");
test();
console.log("After test");

If await yielded control to the runtime and created a macrotask boundary, the timer might run first:

Before test
Inside test
After test
timeout
After await

But it never does. We instead observe:

Before test
Inside test
After test
After await
timeout

The continuation after await always runs before the timer. This matches the rule from the last article:

Microtasks are drained before any macrotask is selected.

await does not create a macrotask.

Mental Model C: The Only Survivor

So far, the only model consistent with every test is:

When execution reaches await, the function pauses and the rest of the function is queued as a microtask.

When JavaScript reaches await value, the engine conceptually performs something like:

Convert value into a promise if it isn’t one already.
Wrap the rest of the function in a continuation.
Schedule the continuation as a microtask.
Return immediately to the caller.

The function simply splits at this point. This happens even if the value is already resolved:

async function test() {
  console.log("Inside test");
  await 42;
  console.log("After await");
}

console.log("Before test");
test();
console.log("After test");

We still observe:

Before test
Inside test
After test
After await

Even though 42 is not a promise, the remainder of the function runs later.

await will also split the function however many times it appears in the function. Consider:

async function test() {
  console.log("Inside test");
  await Promise.resolve();
  console.log("After first await");
  await Promise.resolve();
  console.log("After second await");
}

console.log("Before test");
test();
console.log("After test");
setTimeout(() => console.log("timeout"), 0);

Observed:

Before test
Inside test
After test
After first await
After second await
timeout

Each await causes the function to split with each await creating a new continuation that runs as a microtask. Both continuations run before the timer since the runtime drains microtasks fully before scheduling the next macrotask.

That split results in a pause in the current async function. There is no other pause - not in the call stack, the event loop nor the entire program.

With await, control immediately returns to the caller. That’s why this works:

async function loadData() {
  await fetch("/data");
  console.log("done");
}

console.log("start");
loadData();
console.log("continue");

Output:

start
continue
done

The function pauses and the program continues.

`async`/`await` As Syntactic Sugar Over Promises

You may have heard that async/await is syntactic sugar over promises. That’s true, but only if we are precise what the sugar expands into. At its core, await is equivalent to calling .then() but with one addition.

When JavaScript reaches await value, it registers a continuation like .then() would but it also splits the current function at that point and schedules the remainder to run later as a microtask.

With raw .then(), you manually place the continuation inside a callback. With await, the language automatically pauses the function, preserves its local variables and control flow and resumes it later in the microtask queue. It is a function split backed by the microtask system.

await is .then() plus structured function splitting and microtask resumption.

What About `async`?

So far, we’ve focused entirely on await. But every example also had async. If await is responsible for splitting the function, what does async actually do? Let’s see.

async function test() {
  return 42;
}

async function main() {
  const p1 = test();
  console.log("Without await:", p1);

  const p2 = await test();
  console.log("With await:", p2);
}

main();

The output:

Without await: Promise { 42 }
With await: 42

The main() function runs synchronously until the first await. When test() is called without await, there is no pause and no microtask. The body of test() runs immediately. The only difference is that test() returns a Promise.

async on its own does not introduce asynchronous work. Instead, it changes the return type of the function: test() returns a Promise, even if it completes synchronously.

When test() is called with await, something different happens. The call to test() still runs immediately, and it still returns a Promise. But now main() pauses at the await. The remainder of main() is wrapped into a continuation and scheduled as a microtask. When that microtask runs, the Promise returned by test() is unwrapped and its resolved value becomes the value of the await expression.

Without await, p is a Promise. With await, p is the resolved value of that Promise.

The Correct Mental Model

We can now separate the two keywords clearly:

async changes what the function returns.
await changes how the function executes.

If there is no await, an async function can run entirely synchronously. If there is an await, the function splits and resumes as a microtask continuation.

Once you see this, async/await stops being mysterious. It becomes a thin layer over the microtask system.

What This Prepares Us For Next

We now understand:

Macrotasks are chosen one at a time.
Microtasks drain completely.
Promise callbacks are continuations.
await creates microtask continuations.

There is one more piece missing:

When does rendering happen?

To answer that we need to look beyond JavaScript execution and into the browser's frame lifecycle. That is the next layer of the event loop, and that's where we go next.

This article was originally published on my website.

Microtasks: Why Promises Run First

Marsha Teo — Thu, 23 Apr 2026 08:10:16 +0000

This is the third article in a series on how JavaScript actually runs. You can read the full series here or on my website.

In the last article, we established that:

JavaScript execution cannot be interrupted.

Once a macrotask starts, nothing cuts in. Only after it completes does the runtime select the next macrotask from the queue.

But consider this:

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

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

console.log("sync done");

The output is always:

sync done
promise
timeout

Both setTimeout and Promise.then are asynchronous and both schedule work to run later. If macrotasks are chosen one at a time, and nothing interrupts them, then promises should behave like timers. But that's not the case. The promise runs first, every time. Why?

If our macrotask model of JavaScript were complete, this ordering would not be guaranteed. Something else must exist. Specifically, there is another category of work in JavaScript: microtasks.

They do not interrupt the current macrotask. And yet they run before the runtime selects the next macrotask. Before we define them fully, we should understand why such a mechanism is needed.

The Tempting but Incomplete Explanation

Many explanations jump immediately to:

“Promises use the microtask queue, which runs before the macrotask queue.”

That statement is technically correct. But it explains nothing. Why are there two queues? Why does one outrank the other?

If we stop here, microtasks feel arbitrary. Let's instead find out more.

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.

A Hypothesis: Promises Are Just Higher-Priority Tasks

A reasonable mental model is that microtasks are just higher-priority tasks. When we have timers and promises, timers go into one queue, promises go into another, and the promise queue is checked first.

Let's test this:

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

Promise.resolve().then(() => {
  console.log("promise 1");
  Promise.resolve().then(() => {
    console.log("promise 2");
  });
});

console.log("sync done");

If promises are merely higher-priority tasks, we may expect:

sync done
promise 1
timeout
promise 2

After sync done, the runtime has at least two pending pieces of work: the timer callback and the first promise callback. Since promise callbacks have higher priority, the runtime chooses the promise first. Consequently, promise 1 runs before timeout.

When promise 1 runs, it schedules another promise callback: promise 2. At this point, the runtime could choose between the existing timer callback or the newly scheduled promise callback. If promise callbacks were just higher priority macrotasks, the runtime should be free to interleave them.

However, the actual output is:

sync done
promise 1
promise 2
timeout

promise 2 runs immediately after promise 1, before the timeout is even considered.

The Rule That Must Exist

The only model consistent with this behavior is:

Once microtask execution begins, all microtasks must run to completion before the runtime considers another macrotask.

Promise callbacks are not independent tasks competing with timers. They are unfinished work from the current turn of execution. They are continuations and continuations must complete before control is returned to the runtime.

Reframing Microtasks Properly

A microtask is not a faster callback nor is it a convenience queue. Promise callbacks are the most common example of microtasks, but this mechanism also underlie async functions and MutationObserver callbacks. Broadly, a microtask is:

Work that must be completed before JavaScript yields control back to the runtime.

This is why:

microtasks run after the current macrotask finishes,
microtasks run before the runtime chooses another macrotask,
the runtime drains the microtask queue completely,
microtasks can schedule more microtasks,

They exist to preserve atomicity across asynchronous boundaries.

Why This Rule Must Exist

If microtasks were treated like ordinary macrotasks, promise chains could interleave with unrelated work. That would introduce subtle inconsistencies and expose partially completed state.

Consider this:

let state = {
  loading: true,
  data: null
};

Promise.resolve().then(() => {
  state.data = "result";
  state.loading = false;
});

This callback represents a single logical transition where the data arrives and loading ends. From the programmer's perspective, these two assignments belong together.

If the runtime were allowed to pause this callback midway or run unrelated macrotasks before it completes, external code could observe:

{ loading: true, data: "result" }

This is a partially completed update (data has arrived but loading is still true). JavaScript avoids this by enforcing:

Once the current macrotask finishes, the runtime runs all microtasks run before selecting another macrotask.

This ensures that promises are continuations of the current turn of execution. And these continuations must complete before control returns to the runtime. That guarantee makes promise chains predictable:

Promise.resolve()
  .then(() => step1())
  .then(() => step2());

The first .then() callback is queued as a microtask. After the promise returned by step1() settles, the second callback is queued. A promise chain schedules its continuations incrementally, not all at once.

Yet because the runtime must drain the microtask queue completely before selecting another macrotask, these incrementally scheduled callbacks still run back-to-back, without unrelated timers or events cutting in between them. The continuation may be deferred but it is never fragmented.

The Draining Behavior

Microtasks are not executed one-by-one with runtime checks between them. They are drained in a loop:

while (microtask queue is not empty) {
  run next microtask
}

That is why nested promises run immediately. That is why infinite promise loops freeze the page. Consider:

function loop() {
  Promise.resolve().then(loop);
}

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

loop();

If you run this, be prepared to close the page, since this experiment creates an infinite microtask loop.

The page would freeze and timeout fired is never logged since a new microtask is queued every time loop is called. The runtime is not allowed to proceed to another macrotask while microtasks remain. Microtasks are not candidates for task selection. They are executed automatically as part of finishing the current turn.

The JavaScript Turn Model

We can now describe a single turn of JavaScript execution:

The runtime chooses a macrotask.
JavaScript executes synchronously.
Once the call stack is empty, the runtime drains the microtask queue.
Only then can the runtime consider another macrotask.

This is the event loop from JavaScript's perspective. In later articles, we will extend this model to include rendering and the browser's frame lifecycle. loop.

The Mental Model to Keep

When debugging async behavior, ask:

Did we just finish a macrotask?
Are there microtasks pending?
Has the runtime been allowed to choose another macrotask yet?

If microtasks exist, the answer is always:

No, the runtime must wait.

What This Prepares Us For Next

If microtasks are mandatory continuations, then what exactly does await do?

Does it pause execution?
Does it create a new task?
Or does it quietly hook into this same microtask mechanism?

Understanding that requires looking at async functions more closely.

That is the subject of the next article.

This article was originally published on my website.

Macrotasks: What a Task Actually Is

Marsha Teo — Fri, 17 Apr 2026 13:48:14 +0000

This is the second article in a series on how JavaScript actually runs. You can read the full series here or on my website.

In the previous article, we established that

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

This explains why timers don't cut in, why promises wait and why loops block everything else. But if JavaScript runs 'inside a task', where does that task begin and end? Is the entire script one task? Is each function call its own task?

This article exists to answer more precisely:

What exactly is a task?

The Wrong Mental Model of a Task

You would think that 'task' refers to a unit of work — something with a duration, a beginning, and an end - and imagine that in JavaScript, a 'task' refers to a big chunk of execution. Maybe each statement is its own task; Each function call creates a new task; Control-flow disruptions using try/catch create task boundaries where the runtime is allowed to pause the current execution to run something else. With this, synchronous code consists of smaller tasks, and execution could be subdivided internally.

Let's test that idea.

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.

Test 1: The Initial Script Is One Task

In the previous article, we tested whether setTimeout could interrupt synchronous execution:

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");

What we always observed was:

sync start
sync end
timeout fired

The entire global script executed as one uninterrupted block. The setTimeout callback ran later in a separate execution window. There are 2 tasks here: the initial script and the timeout callback.

Even though the timer expired quickly, the callback did not execute immediately. Instead, when the timer expired, the callback became eligible to run and waited in the queue managed by the runtime.

Test 2: Internal Structure Does Not Create Task Boundaries

Could each function call be its own 'task' internally? If function calls created new tasks, the runtime could switch between them.

function a() {
  console.log("a");
  b();
}

function b() {
  console.log("b");
  c();
}

function c() {
  console.log("c");
}

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

a();

If function calls created new tasks, we might expect the timeout to run between a, b, or c.

But the output is always:

a
b
c
timeout

Even though the call stack grows and shrinks, JavaScript remains inside the same task the entire time. Function calls change the call stack but do not create new tasks because these changes to the internal call stack are invisible to the runtime. The runtime only observes whether the call stack is empty.

This is the case even in deep recursion cases:

console.log("start")

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

function recurse(n) {
  if (n === 0) return ;
  recurse(n - 1);
}

recurse(100);

console.log("end");

The runtime does not care how long the call stack is:

start
end
timeout

Test 3: Exceptions Do Not Create Task Boundaries

Perhaps abrupt control flow — like exceptions — creates a task boundary. Maybe now execution 'breaks' enough that the runtime gets a chance to run something else.

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

try {
  console.log("before throw");
  throw new Error("boom");
} catch {
  console.log("caught error");
}

console.log("after catch");

The output is always:

before throw
caught error
after catch
timeout

Even though execution jumps abruptly from throw to catch, it never leaves the current task. JavaScript remains in the same task until after catch and the runtime schedules the timer callback task.

Now let's remove the try/catch:

setTimeout(() => console.log("timeout task"), 0);

function a() {
  console.log("a: enter");
  try {
    b();
  } finally {
    console.log("a: finally (ran during unwind)");
  }
  console.log("a: after b (never)");
}

function b() {
  console.log("b: enter");
  try {
    c();
  } finally {
    console.log("b: finally (ran during unwind)");
  }
}

function c() {
  console.log("c: throw");
  throw new Error("boom");
}

a();
console.log("global: after a (never)");

What happens?

a: enter
b: enter
c: throw
b: finally (ran during unwind)
a: finally (ran during unwind)
Uncaught Error: boom
timeout task

Control never returns to a: after b or global: after a after the exception was thrown. The current task terminates immediately when the error escapes the call stack. As the stack unwinds, the finally blocks run. Only after the unwind is complete does the runtime regain control and select select the next task. An uncaught exception ends the current task. It does not subdivide it.

Test 4: User Events Do Not Interrupt

Now let's introduce an external event: a user click.

document.addEventListener("click", () => {
  console.log("click handler ran");
});

console.log("start long task");

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

console.log("end long task");

If you click the page while the loop is running, what happens?

The page will appear frozen for a few seconds (the loop typically takes a couple of seconds to complete on most machines). The click is detected instantly by the browser but the click handler does not run. Only after the loop finishes do you see:

start long task
end long task
click handler ran

The click created a new task: the runtime (the browser) captured the click event and scheduled the task. That task waits for the engine to become idle.

Reframing Tasks Correctly: Permission, Not Duration

A task describes why JavaScript is allowed to start running at all.

The runtime (the browser or Node.js) observes events outside the JavaScript engine. These events include timers expiring and user interactions. Each of these produces a request to run JavaScript. A task is that request.

A task does not describe how long JavaScript runs. It describes an entry point into execution. For instance, the delay passed to setTimeout is a minimum delay, not a guaranteed execution time. When the timer expires, the callback becomes eligible to run. It does not execute immediately. It must still wait for the current task to finish and for the call stack to become empty.

When the call stack is empty, the runtime chooses one task and hands control to the engine. The JavaScript engine then runs that task synchronously to completion.

From the runtime’s point of view, the engine is either running or idle. An empty call stack is the only signal that matters. The runtime is free to wait, listen, and prepare callbacks — but it is not free to execute them whenever it likes. It must wait until JavaScript stops.

Tasks are a coordination mechanism between the runtime and the engine.

Why These Are Called "Macrotasks"

The kind of task we have been discussing has a more precise name: macrotask. Examples include the initial script execution, a setTimeout callback and a user event handler.

"Macro" does not mean large nor long-running. It distinguishes these tasks from another scheduling mechanisms we will introduce in the next article.

For now, a macrotask is:

a request from runtime that allows the engine to begin executing code.

The Runtime Model

At this point, we can describe the system precisely:

The runtime collects requests to run JavaScript.
Each request is a macrotask.
When the call stack is empty, the runtime selects a macrotask.
JavaScript runs synchronously to completion.
Only then can another macrotask be considered.

From the runtime's perspective, the only thing that matters is whether the call stack is empty.

This explains why task boundaries are coarse. Task boundaries do not occur between statements, function calls, loop iterations, recursive calls nor try/catch blocks. They occur at large structural entry points like an entire script, an entire event handler, or an entire timer callback. The runtime does not see internal structure; It only sees whether execution has finished.

Where We Go Next

At this point, we know that a macrotask runs to completion. But what happens when, inside a macrotask, the code schedules more work that logically belongs to the same operation?

Should it interrupt the current macrotask? (But we just established that this is not possible).

Should it wait behind the other tasks in the queue? (But this would delay it unpredictably.)

Neither is ideal. Instead, JavaScript has a mechanism that does not interrupt the current macrotask but runs before the runtime selects the next macrotask. This mechanism is microtasks.

This is where we go next.

This article was originally published on my website.

The JavaScript Runtime: Fixing the Mental Model

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

This is the first article in a series on how JavaScript actually runs. You can read the full series here or on my website.

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.

This article was originally published on my website.

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

You can also read this series on my website (recommended for the best reading experience).

The articles

Here’s how the model unfolds:

1) The JavaScript Runtime: Fixing the Mental Model

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.

Read it here

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.

Read it here

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.

Read it here.

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.

Read it here

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

This series was originally written and is maintained on my website. If you prefer a single place with all updates and future articles, you can follow along there.

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

My personal website is https://marshateo.com.

DEV Community: Marsha Teo

Rendering Is a Browser Decision, Not a JavaScript One

Rendering Is a Browser Decision

The Rendering Misconception

Running the Experiments

Test 1: DOM Updates Inside One Macrotask

Test 2: Microtasks Also Delay Rendering

Test 3: Breaking Into a New Task Allows Paint

Why Rendering Waits

The Correct Mental Model

What This Prepares Us For Next

async / await: Pausing a Function Without Pausing JavaScript

The Possible Mental Models

Running the Experiments

Test for Mental Model A (await Blocks)

Test for Mental Model B (await Yields)

Mental Model C: The Only Survivor

async/await As Syntactic Sugar Over Promises

What About async?

The Correct Mental Model

What This Prepares Us For Next

Microtasks: Why Promises Run First

The Tempting but Incomplete Explanation

Running the Experiments

A Hypothesis: Promises Are Just Higher-Priority Tasks

The Rule That Must Exist

Reframing Microtasks Properly

Why This Rule Must Exist

The Draining Behavior

The JavaScript Turn Model

The Mental Model to Keep

What This Prepares Us For Next

Macrotasks: What a Task Actually Is

The Wrong Mental Model of a Task

Running the Experiments

Test 1: The Initial Script Is One Task

Test 2: Internal Structure Does Not Create Task Boundaries

Test 3: Exceptions Do Not Create Task Boundaries

Test 4: User Events Do Not Interrupt

Reframing Tasks Correctly: Permission, Not Duration

Why These Are Called "Macrotasks"

The Runtime Model

Where We Go Next

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 for Mental Model A (`await` Blocks)

Test for Mental Model B (`await` Yields)

`async`/`await` As Syntactic Sugar Over Promises

What About `async`?

Test 1: Can `setTimeout` Interrupt a Loop?