Forem: Marsha Teo

The Scheduling Boundaries Behind Responsive UI

Marsha Teo — Mon, 18 May 2026 05:35:33 +0000

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

We now know how the event loop and rendering pipeline behave.

The browser:

Runs a macrotask to completion.
Drains all microtasks.
Executes any scheduled requestAnimationFrame callbacks.
Drains all microtasks.
Performs layout and paint to produce the next frame.
Moves on to the next macrotask.

Given that environment, how should we write UI code?

Long Tasks Block Everything

If you want the UI to stay responsive, your tasks must yield quickly.

Consider this:

button.addEventListener("click", () => {
  const start = performance.now();

  while (performance.now() - start < 3000) {
    // busy loop for 3 seconds
  }

  console.log("done");
});

Once the button is clicked, the page becomes unresponsive. The click handler is a macrotask and nothing can interrupt it. Everything else has to wait: there is no re-rendering, no new input, no requestAnimationFrame callbacks.

Long-running tasks monopolize the main thread. While they run, rendering pauses, input waits, animations stall and timers are delayed. Responsive UI depends on cooperation.

Microtasks Do Not Yield to Rendering

Chaining promises look like a way to break work into pieces:

button.addEventListener("click", () => {
  Promise.resolve()
    .then(() => heavyWork())
    .then(() => {
      status.textContent = "Halfway...";
    })
    .then(() => moreHeavyWork())
    .then(() => {
      status.textContent = "Done";
    });
});

However, each .then() callback becomes a microtask when its associated Promise resolves. Because the browser must drain the entire microtask queue before rendering, chaining Promises does not create render opportunities. As a result, the user sees nothing until "Done" shows up on screen.

If you want to let the browser render, you must introduce a scheduling boundary:

button.addEventListener("click", () => {
  Promise.resolve()
    .then(() => heavyWork())
    .then(() => {
      status.textContent = "Halfway...";

      return new Promise(resolve => {
        // setTimeout used to introduce a scheduling boundary
        setTimeout(resolve, 0); 
      });
    })
    .then(() => heavyWork())
    .then(() => {
      status.textContent = "Done";
    });
});

Alternatively, we can consider:

button.addEventListener("click", () => {
  Promise.resolve()
    .then(() => heavyWork()
    .then(() => {
      status.textContent = "Halfway...";

      return new Promise(resolve => {
        // requestAnimationFrame used to introduce a scheduling boundary
        requestAnimationFrame(resolve); 
      });
    })
    .then(() => heavyWork()
    .then(() => {
      status.textContent = "Done";
    });
});

Both approaches work because a .then() callback is only queued once its associated Promise resolves. By returning a Promise that resolves later, we delay when the next microtask is created. setTimeout yields to the next macrotask, while requestAnimationFrame yields to the next frame.

Choosing Between Promises, `setTimeout` and `requestAnimationFrame`

These mechanisms signal different intentions to the browser. They are not interchangeable.

Use a Promise when you need to continue work immediately after the current macrotask completes, but before the browser moves on. They are ideal for continuing work that logically depends on previous work. They help to preserve order, transform results and update state after completion. They are not a yielding mechanism.

Use setTimeout when you need to create a real scheduling gap. They are useful for breaking up long computation, deferring non-critical work and yielding cooperatively. They are general purpose yields.

Use requestAnimationFrame when you are performing visual updates. It is ideal for animations and layout-sensitive work.

Different scheduling APIs solve different coordination problems in the browser event loop.

Align Visual Updates to Frames

Consider this approach:

document.addEventListener("mousemove", (event) => {
  box.style.left = event.clientX + "px";
});

If the mouse fires 200 events per second, this code attempts 200 DOM updates per second. But on most displays, the refresh happens about 60 times per second. Visual work that exceeds that rate is simply wasted.

Instead, consider:

let latestX = 0;
let scheduled = false;

document.addEventListener("mousemove", (event) => {
  latestX = event.clientX;

  if (!scheduled) {
    scheduled = true;

    requestAnimationFrame(() => {
      box.style.left = latestX + "px";
      scheduled = false;
    });
  }
});

We use requestAnimationFrame to update at most once per frame, no matter the rate at which input can fire.

Respect the Frame Budget

requestAnimationFrame guarantees alignment to the frames but it does not guarantee smoothness. On a 60fps display, the browser has roughly 16ms per frames. That 16ms must include all JavaScript and rendering work.

If the JavaScript executed alone takes longer than that, the browser cannot complete rendering in time:

requestAnimationFrame(() => {
  const start = performance.now();

  while (performance.now() - start < 40) {
    // 40ms of work
  }
});

This callback runs before the browser renders but it blocks for 40ms and therefore exceeds the frame budget. Since the browser cannot display partial frames, if the 16ms window is missed, that frame is dropped. Instead of rendering at 60 frames per second, the browser renders less frequently: Animations can appear jerky, motion uneven and interactions delayed.

So while requestAnimationFrame helped with alignment, we must still finish the frame work within the frame window. Either work fits inside the budget or it is spread across multiple frames. For instance, this could mean animating in steps or deferring non-critical computation.

Responsive UI requires both correct scheduling and work that fits inside the budget.

Guard Against Stale Asynchronous Work

Asynchronous code creates delays. During this window, state can change:

function loadData() {
  fetch("/data")
    .then(response => response.json())
    .then(data => {
      render(data);
    });
}

This looks harmless but imagine the user clicking twice quickly and loadData() is called twice in succession. If the second request finishes first, the first request would render stale data and the UI would then be incorrect.

One common pattern is to guard against outdated work:

let currentRequestId = 0;

function loadData() {
  const id = ++currentRequestId;

  fetch("/data")
    .then(response => response.json())
    .then(data => {
      if (id !== currentRequestId) return;
      render(data);
    });
}

Now each request captures its own response and only the most recent request is allowed to update the UI.

Designing With the Browser, Not Against It

Responsive UI emerges from working within the browser's execution model.

In practice, that often means:

Keeping tasks short so the browser can continue scheduling
Remembering that microtasks do not yield to rendering
Aligning visual updates to frame boundaries
Ensuring that work fits within the frame budget.
Verifying that delayed work is still relevant before applying it

I started this series because I had code that used Promises, setTimeout, and requestAnimationFrame. They all felt “asynchronous” and interchangeable. Turns out they weren't.

Good UI code knows which scheduling boundary to use and when.

This article was originally published on my website.

requestAnimationFrame: The Missing Scheduling Layer

Marsha Teo — Fri, 08 May 2026 16:50:01 +0000

This is the sixth 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:

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

Instead, rendering only happens at stable boundaries. But this creates a new problem: If rendering only happens at specific boundaries, how do we run code just before a render? If we want smooth animation, frame-aligned updates, or visual state that reflects the latest input, we need something that runs once per frame right before the browser renders.

That is the scheduling gap that requestAnimationFrame fills.

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.

The Problem Before `requestAnimationFrame`

Developers originally faced a challenge:

How do I animate smoothly without freezing the UI?

We may run a naive loop like this where we want update() to advance state and render() to mutate the DOM or canvas:

let gameRunning = true;

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

function render() {
  console.log("render");
  const box = document.getElementById("box");
  box.textContent = `Updated at ${new Date().toLocaleTimeString()}`;
}

while (gameRunning) {
  update();
  render();
}

This will freeze your browser. Be prepared to close the browser tab after running this.

This code completely blocks rendering. Since the call stack never empties, the browser never regains control and no rendering can occur. The page never updates.

So developers sliced work into smaller chunks to allow for breathing space for the browser to render:

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

function render() {
  console.log("render");
  const box = document.getElementById("box");
  box.textContent = `Updated at ${new Date().toLocaleTimeString()}`;
}

function loop() {
  update();
  render();
  setTimeout(loop, 16); // Use setTimeout() to chunk work
}
loop()

While this doesn't freeze the browser, be prepared to refresh the browser tab after running this.

Now, the page renders the updates (the time shown on the page updates) to the box content. Since most screens refresh at 60 Hz, 16 ms (1000 ms / 60 Hz) seemed like the right delay. This allowed the stack to clear between iterations so that the browser could render.

But this was still guesswork.

But this approach was not without its problems. First, timers are minimum delays, not guarantees. The callback may run for 20ms, 30ms or later. Also, if the callback took longer than 16ms, we would miss frames and accumulate jitter and drop frames. Consequently, the callback may run before or after the render.

Fundamentally, rendering is framed-based while timers are time-based, and therefore do not know when the browser is about to render.

Enter `requestAnimationFrame`

requestAnimationFrame solves exactly this problem:

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

function render() {
  console.log("render");
  const box = document.getElementById("box");
  box.textContent = "Updated at " + new Date().toLocaleTimeString();
}

function loop() {
  update();
  render();
  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);

This also doesn't freeze the browser but be prepared to refresh the browser tab after running this.

As before, the page renders the updates on the page. However, unlike timers, this runs before rendering. This sounds great but where exactly does it fit in the event loop model? Let's find out.

Test 1: Does `requestAnimationFrame` Cut Ahead of Microtasks?

If requestAnimationFrame runs just before rendering, it must not violate our previous rules:

Promise.resolve().then(() => {
  console.log("microtask");
});

requestAnimationFrame(() => {
  console.log("raf");
});

The output in the console would be:

microtask
raf

As established, the browser does not render while microtasks are pending. Microtasks still run first and requestAnimationFrame does not change that.

Test 2: Is `requestAnimationFrame` Just Another Task?

If requestAnimationFrame were simply another macrotask, it would behave like setTimeout and follow the ordering of tasks:

console.log("start");

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

requestAnimationFrame(() => {
  console.log("raf");
});

console.log("end");

In practice, you will often see the following in the console:

start
end
timeout
raf

However, you may also see:

start
end
raf
timeout

The ordering is not guaranteed. Even if your environment consistently shows one ordering, the key point is that the model does not enforce it. The browser is allowed to process another task first, or perform a render before continuing with tasks. Because of this, there is no fixed ordering between setTimeout and requestAnimationFrame.

This might seem surprising. If requestAnimationFrame were just another macrotask, we would expect it to follow a consistent ordering relative to setTimeout. But it doesn’t, suggesting that requestAnimationFrame is not part of the task queue at all. Instead, it runs during the browser’s rendering phase, which is scheduled separately from tasks.

Test 3: Do Microtasks Inside `requestAnimationFrame` Run Before Paint?

What if requestAnimationFrame also created microtasks?

requestAnimationFrame(() => {
  const box = document.getElementById("box");

  box.textContent = "Frame start";

  Promise.resolve().then(() => {
    box.textContent = "Microtask update";
  });
});

The typical output is for the page to show "Microtask update"

When the requestAnimationFrame callback runs, the DOM updates and a microtask is queued. The requestAnimationFrame callback completes and microtasks drain. Only then can rendering occur.

Even inside requestAnimationFrame, microtasks must drain before rendering.

What `requestAnimationFrame` Actually Guarantees

requestAnimationFrame guarantees that the callback runs before the browser's rendering. It runs at most once per frame and is aligned to the display's actual refresh rate, regardless of whether it is 60Hz or 120Hz. It pauses automatically in background tabs and skips frames when the browser is busy.

The Complete Ordering

We can now state the model:

Macrotask
Drain microtasks
requestAnimationFrame callbacks
Drain microtasks
Render

This is the complete scheduling turn. Rendering is not part of task queue but is gated by it. requestAnimationFrame is the only public API designed to hook into that pre-render phase.

What This Prepares Us For Next

Now that we understand this structure, what do we do with it?

In the final article of this series, we move from mechanism to consequence:

What happens when a macrotask runs too long?
What happens when microtasks never stop?
Why does the UI freeze?
Why are some updates never visible?
Why do we sometimes need cleanup guards?

One we understand who gets to run and when, we can reason about performance, responsiveness and architectural trade-offs with precision.

This is where we go next.

This article was originally published on my website.

I Thought Dark Mode Was a 30-Minute Task. It Turned Into a Full Refactor

Marsha Teo — Wed, 06 May 2026 11:24:11 +0000

I thought adding dark mode would take 30 minutes. It broke my website.

Problem 1: Hardcoded colours

I didn’t even use that many colours. How hard could it be? Turns out, very.

My colours were hardcoded directly into Tailwind utility classes. A heading had a specific hex value, and a paragraph had another. To change the theme, I would have had to update each of these individually. No, thank you.

The fix

I introduced CSS variables and defined colours by role, not value.

My first attempt had variables like hover-dark and hover-darker. That worked until I tried to invert the theme for dark mode. What would hover-darker even mean in dark mode?

Instead of asking "What color should this element be?", I had to ask "What role does this color play?"

So I switched to variable names that were semantic, rather than literal:

--text-primary
--text-secondary
--background
--border

With this, a heading wasn’t “black” anymore. It was text-primary. A background wasn’t “white”. It was background-primary.

At this point, I thought I was mostly done. I wasn’t even close.

Problem 2: Dark mode is not white on black

I thought dark mode meant white text on a black background. It looked terrible. Who would've thought that having white text on black would feel so... bright? It was harsh, hard to read, and everything started blending together - almost like I had suddenly developed astigmatism.

The fix

It turns out dark mode isn't really black and white. It's shades of grey. Instead of white, I used a light grey and text was miraculously legible again. For secondary text, even lighter grey worked perfectly.

Pushing contrast to the extreme with white text on black backgrounds was a disaster. Tuning that contrast and making it proportionate and layered made things way more comfortable.

White text on black was too much contrast on my screen. I felt it in my eyes.

Subtle change to reduce contrast, making it easier to read over a longer period of time

And that's all my problems solved, said no one ever.

Problem 3: Everything breaks differently

Even after fixing colours, things still looked off. Different parts of the UI broke in different ways:

Problem 3.1: Typography (Tailwind)

Tailwind’s typography plugin (prose) worked great in light mode. But once I introduced my own variables, the defaults started conflicting with my system. Some styles updated, others didn’t. Fixing one thing broke another. The abstraction broke down, and the complexity I’d tried to hide came rushing back.

The fix

I explicitly mapped Tailwind’s typography variables to my own. Instead of relying on defaults, I treated typography as part of my system.

Once everything pointed back to the same set of variables, things became predictable again.

Problem 3.2: Code Syntax Highlighting

I use a lot of code snippets, especially in my JavaScript event loop article series. For syntax highlighting, I had used Github's light theme for my light mode. Too bad it was impossible to read in dark mode. So I switched to Github Dark CSS - only for it to look off in light mode.

The fix

For a while, I assumed I had to pick one. Eventually, I realised the obvious solution: use both Github and Github Dark CSS and switch dynamically based on the mode. It sounds pretty obvious now, but at the time, I genuinely thought I had to choose.

Github's light theme in dark mode was impossible to read

Github's dark theme in light mode looked washed out

Problem 3.3: Images

Images introduced a different kind of problem. Some worked fine. Others didn’t translate at all.

My hero image is of a sunrise. From the start, I imagined using a sunset version for dark mode. Did I create dark mode just so that I can use this image? Maybe.

Thankfully, this was easily implemented by including both images and switching between them based on the mode.

But my SVG diagrams were harder. I tried making their colors dynamic using CSS variables but it didn’t work reliably.

The fix

Instead of forcing everything to be dynamic, I created two versions of each diagram, one for each mode. It felt less elegant at first, but it worked better. Not everything should be dynamically styled.

Diagrams designed for light mode don’t translate automatically.

Problem 4: The flash

After fixing everything, I refreshed the page. A flash of light mode appeared before it switched to dark. It was subtle, but definitely there. And yes, the temptation to pretend that didn't happen was definitely there too.

The browser was rendering before the correct theme was applied. By the time JavaScript the correct theme was set, the browser had already painted the wrong one.

The flash: light mode renders before dark mode is applied

The fix

The theme needed to be determined before rendering. Moving the theme logic earlier removed the flash entirely. It was a small change technically, but it had a big impact on how the site felt.

The real lesson

I thought I was adding a feature: a toggle button and a visual enhancement that sits on top of everything else.

But dark mode didn’t sit on top of my UI. It ran through it and every part of the system had to agree. None of the above was individually difficult. But together, they revealed that dark mode was a system and one that needs to be designed intentionally.

If you’re implementing dark mode

A few things I wish I knew earlier:

Define colors by role, not value
Avoid extreme contrast
Treat typography as part of your system
Don’t force everything to be dynamic
Handle theme selection before render

If you’re curious, the full implementation and visuals are on my site. This article was also originally published there.

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.

Read it here.

7) The Scheduling Boundaries Behind Responsive UI

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.

Read it here

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.

Forem: Marsha Teo

The Scheduling Boundaries Behind Responsive UI

Long Tasks Block Everything

Microtasks Do Not Yield to Rendering

Choosing Between Promises, setTimeout and requestAnimationFrame

Align Visual Updates to Frames

Respect the Frame Budget

Guard Against Stale Asynchronous Work

Designing With the Browser, Not Against It

requestAnimationFrame: The Missing Scheduling Layer

Running the Experiments

The Problem Before requestAnimationFrame

Enter requestAnimationFrame

Test 1: Does requestAnimationFrame Cut Ahead of Microtasks?

Test 2: Is requestAnimationFrame Just Another Task?

Test 3: Do Microtasks Inside requestAnimationFrame Run Before Paint?

What requestAnimationFrame Actually Guarantees

The Complete Ordering

What This Prepares Us For Next

I Thought Dark Mode Was a 30-Minute Task. It Turned Into a Full Refactor

Problem 1: Hardcoded colours

Problem 2: Dark mode is not white on black

Problem 3: Everything breaks differently

Problem 4: The flash

The real lesson

If you’re implementing dark mode

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

Choosing Between Promises, `setTimeout` and `requestAnimationFrame`

The Problem Before `requestAnimationFrame`

Enter `requestAnimationFrame`

Test 1: Does `requestAnimationFrame` Cut Ahead of Microtasks?

Test 2: Is `requestAnimationFrame` Just Another Task?

Test 3: Do Microtasks Inside `requestAnimationFrame` Run Before Paint?

What `requestAnimationFrame` Actually Guarantees

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?