Forem: Elina Dzhelilova

The Event Loop, Part III: The Unstoppable Train 🚂

Elina Dzhelilova — Mon, 05 Jan 2026 18:16:29 +0000

One track. One train. No overtaking.
👋 Hey folks!

In Part I and Part II, we discussed the Illusion: why browsers appear "instant" to Muggles (users) 🧑‍, and why that illusion breaks when we interact with the DOM.

Now, we strip away the magic and look at the foundation.
No Event Loop yet.
No microtasks.
No queues.

Only the thing that always happens first.

🚂 The Call Stack is a Train That Does Not Stop

Imagine the Hogwarts Express.

It has one track (The Main Thread 🧵).
It moves in one direction.
While the train is on the track, nothing else can move.

This is your Call Stack.

JavaScript is synchronous by nature. It is single-minded. It executes spells (code) step-by-step and never gives up control halfway through.

The browser? Sure, it’s asynchronous. It has networking, timers, the rendering engine, the GPU… But JavaScript itself? It sits comfortably in the Call Stack, blocking the view.

And while the Call Stack is busy, the track is closed. ⛔️

🧪 Scenario 1: The Sync Trap (Click vs. .click())

Let’s look at a spell that confuses many wizards. We have a button, a listener, and some logs.

console.log("A: script start");

button.addEventListener("click", () => {
  console.log("B: click start");

  // 🪄 Synchronous array magic
  const items = [1, 2, 3];
  items.map((n) => {
    console.log("C: map:", n);
    return n * 2;
  });

  button.classList.add("active");
  console.log("D: class added");

  // 🦉 Future work (Async)
  Promise.resolve().then(() => {
    console.log("E: Promise.then");
  });

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

  console.log("G: click end");
});

console.log("H: before click");

// ⚠️ Crucial moment: We trigger the click SYNCHRONOUSLY
button.click();

console.log("I: after click");

console.log("J: script end");

The Output 📜

A: script start
H: before click
B: click start
C: map: 1
C: map: 2
C: map: 3
D: class added
G: click end
I: after click
J: script end
E: Promise.then
F: setTimeout

Why This Happens (The Magic Mechanics) ⚙️
Look closely at I: after click. It appears after the entire click handler runs (logs B, C, D, and G).

Why? Because button.click() is a synchronous command.

The script runs H: before click.

It hits button.click() and immediately jumps into the addEventListener function.

It must finish that entire function (running through G: click end) before it can return to the main flow to print I: after click and J: script end.

The Rule: The train is moving. Passengers (code lines) exit strictly in boarding order. Async tasks (Promises like E and Timeouts like F) are thrown out of the window to catch a later train. 👋

🧪 Scenario 2: Immediate Magic (No Clicks)

console.log("A: script start");

const el = document.createElement("div");

// 🪄 Direct DOM mutation
el.classList.add("box");
console.log("B: class added");

// ⚠️ Forces Layout (Heavy synchronous calculation)
const height = el.getBoundingClientRect().height;
console.log("C: layout read", height);

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

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

console.log("F: script end");

The Output 📜

A: script start
B: class added
C: layout read 0
F: script end

and only then...

D: Promise.then
E: setTimeout

What Matters Here 🧠

classList.add() is synchronous.
getBoundingClientRect() is synchronous (and expensive!). It forces the browser to calculate geometry right now.
Promises wait. Even if they feel “instant”, they are not allowed on the current train.

No async mechanism can intervene until the Call Stack is empty.

🚗 Where Render Fits In

Rendering (Layout, Paint, Composite) is not part of the Call Stack. Think of Render as the Flying Ford Anglia 🚙 trying to cross the train tracks.

The Ford Anglia is hovering, ready to go.
The engine is roaring (60fps needed!).
The GPU is warmed up.

But: ⛔️ The Ford Anglia cannot cross while the Hogwarts Express 🚂 (Call Stack) is occupying the track.

It doesn’t matter how urgent the paint is. If your while loop is running, or your JSON is parsing, or your map() is iterating, the frame is dropped. The screen freezes. The illusion breaks.

🧑‍🎓 Who Actually Sits in the Call Stack?

When we say “Call Stack”, we don’t mean abstract code. We mean specific synchronous operations that hog the line:

✅ Array.map, filter, reduce
✅ for while loops
✅ classList.add() / remove()
✅ getBoundingClientRect() / offsetWidth
✅ Any function without await

All of them run to completion. All of them fully occupy the Main Thread. None of them let Render sneak in.

😈 Who Can Stop the Train?

The Call Stack cannot stop itself. Once the function starts, it runs until the closing brace.

Only external “Dark Arts” can stop it:

👑 The Browser (killing a frozen tab)
🧊 Debugger (breakpoints)
💥 Crash (Error)

This is not the Event Loop. This is just... The Line.

🧩 Part III Summary

Synchronous execution always comes first.
The Call Stack fully owns the Main Thread.
Render cannot interrupt it.
Promises and timers must wait for the stack to clear.
The train moves until it has completed its route.

🔮 What’s Next?

We have the Line. Now we need the Loop.

In Part IV, we finally meet the messengers:

🦉 Microtasks
💌 Promises

Why does the Owl (Promise) arrive before the Render, but after the sync code? Stay tuned! ✨

💬 Let's Discuss

Have you ever accidentally frozen your browser with a while(true) loop or heavy calculation? Drop your "horror stories" in the comments! 👇

Happy coding! 👩‍💻✨

Elina · WebMagic Mastering the Dark Arts of Web Development

The Event Loop, Part II: The Wand Is Not Yours 🪄 (Or Why the UI Ignores You)

Elina Dzhelilova — Sun, 04 Jan 2026 19:24:51 +0000

Hey folks! 👋

If you missed the start of our journey, where we discussed why the browser lies to users to keep things looking smooth, check it out here 👉 Part I: The Illusion.

Today, we are ripping off the band-aid on a painful topic. The million-dollar question: If my code executes, why the hell doesn’t anything change on the screen?

Let’s be real: we all live in this illusion that JavaScript is in total control. But spoiler alert: the browser often just completely ignores your commands.

The Illusion We Don't Notice 🙈

We are used to writing code with the expectation of "instant karma":
🪄 I changed the DOM — show it.
🪄 The Promise resolved — render the update!
🪄 This line ran — the UI must reflect it.

But it doesn't work like that. JavaScript can change the DOM. But only the Browser decides whether to show those changes.

It's like ordering a pizza: you can place the order (change state), but that doesn't mean the delivery driver (the renderer) is ringing your doorbell right now.

The Browser is Not Just a JS Runtime 🏗️

Modern Chrome or Firefox isn't just a "JavaScript environment." It’s a complex machine where multiple systems work in parallel:

🧩 JS Engine (V8) — executes your code.
🧩 Rendering Engine (Blink) — paints the pixels.

Think of them as neighbours shouting over a fence. They are not the same person. And most importantly: They share the same Main Thread.

Aunt Petunia’s Experiment 🐸

Let’s get to the code. Imagine a classic frontend scenario:

User clicks a button.
We show a loading spinner.
We run a heavy synchronous task (like parsing a massive JSON).
We hide the spinner.

Expectation: The spinner appears, spins for a bit, and vanishes. Reality: ... 🫠

button.addEventListener("click", () => {
  showMagicLoader(); // 🪄 Spell: "Show the spinner!"

  // ⚠️ Warning! Heavy synchronous work.
  // We are blocking the Main Thread completely.
  const response = "[" + "1,".repeat(5_000_000) + "1]";
  JSON.parse(response); // The browser is frozen here 🥶

  hideMagicLoader(); // 🪄 Spell: "Hide the spinner!"
});

What does the user see? Absolutely nothing. The screen just "freezes" for a second and then "unfreezes." The spinner never appeared.

Honesty Check 🔦: did the thought cross your mind that the spinner would appear for at least a millisecond?

If yes — congratulations, you’re a normal developer 😅. I used to think that too. But here is the harsh truth:

Code Execution ≠ Rendering

While JavaScript is busy dealing with your JSON on the Main Thread, the browser physically cannot paint anything. It is blocked. When JS finally finishes the job, it immediately executes hideMagicLoader().

To the browser, the timeline looks like this:
"Oh, JS changed the DOM to show a spinner... but I'm busy executing JS, I'll wait."

"Yup, JS is still going..."
"Oh, JS now says to hide the spinner. Okay."

Result: The spinner existed in the DOM, but it never made it to the Paint stage.

It’s Not a Bug, It’s a Feature (Seriously) 😎.
Browsers aren't optimised for us developers. They are optimised for users. If a state appears and disappears within a single synchronous task (one "tick"), blocking the thread, the browser simply discards it to save resources. Efficient? Yes. Confusing? You bet.

TL;DR / The Takeaway 🎯

Your mental model needs a shift:

JavaScript controls STATE.
The Browser decides REALITY (Rendering).

The illusion breaks when we assume: "If the code ran, the user saw it." This is the curse that leads to "janky" interfaces.

What’s Next? ✨

In the next part (Part 3), we are going to get properly under the hood. 🧱 Call Stack 🧵 Main Thread ⏳ Synchronous Execution

We’ll break down exactly where JS lives, and why—before you can understand the Event Loop—you have to understand "The Queue."

💬 Question for the community:

We have all accidentally "crashed" a browser tab with an accidental infinite loop or heavy recursion. What was the specific operation that first made you realize JS blocks the interface? Drop your stories (and failures) in the comments, let's laugh about it together! 👇

Happy coding! 👩‍💻✨

The Event Loop Is Not Magic — You Just Don’t Know the Spell ✨

Elina Dzhelilova — Sat, 03 Jan 2026 19:06:10 +0000

This part is mostly context and vibes. If you’re here for the technical stuff, skip straight to Part I 👇.
I am a chronic ADHD person, and my brain absolutely refuses to learn complex systems the “normal” way. Long abstract explanations?
Pls, kill me 😑🔫.
Whitepapers? Nope 🥱.

What does work for me is metaphors.
And since I grew up obsessed with the Harry Potter universe, my brain decided that spells, wands, and wizardry are the perfect way to understand how browsers and JavaScript actually work.

Recently, I went way too deep into the Event Loop 🔁, rendering, scheduling, and all the “why does this feel random” browser stuff. At some point, I realized I was basically building my own magical mental model just to survive.

So… this series is me sharing that model.

No “best practices” preaching 🙅‍♀️. Just a wizard trying to explain browser behavior in a way that finally made sense to her.

If this helps you — awesome 🤘.

If it doesn’t — totally fine 🤷‍♀️.

If I got something wrong — please tell me (nicely 🥺🙏).

And yes, there will be magical metaphors. A lot of them. 🧙‍♀️🔮

Let’s go 🚀🪄

Part I: The Illusion 🔮

Engineers often refer to it as “magic.”

Usually, we say this with a sigh of relief when a bug disappears without explanation.

But let’s be honest.

Magic only exists for those who don’t know the spell. 🤫📜

From a muggle’s (user’s 🧑) point of view, the browser performs miracles.

From a wizard’s (developer’s 🧙‍♀️) point of view, those miracles are the result of strict rules, queues, and constraints.

This series is a map of that hidden machinery — not to make you memorize it, but to help you stop trusting the illusion.

Why Everything Looks Instant to Muggles 🐇

From the muggles’ perspective, the interaction looks trivial.

🖱️ Click → 🛒 Purchase → 🎉 Result

The Chocolate Frog is already in the cart. The interface has been updated.

No visible latency. No intermediate states. No sense that a complex mechanism has just executed under the hood. (Or so we’d like to believe 🙃)

To muggles, this looks like magic ✨.

Magic Is Engineered 🪄⚙️

But this magic is not accidental. It is engineered 🏗️.

Modern browsers intentionally hide complexity:

Event parsing
State reconciliation
Network handshakes
Layout recalculation
Paint and composite

Hundreds of operations are collapsed into a single visual moment — roughly one frame (~16ms).

The Wizard’s Debt. Here’s a fun fact no one usually tells you. You don’t actually get the full 16 milliseconds to run JavaScript. The browser takes its cut first — about 6ms for internal housekeeping (style, layout, paint). That leaves you ~10ms to actually run your code.

On a 60Hz display, 16.6ms is your whole world. On a 120Hz ProMotion screen, that budget drops to about 8ms. Miss the deadline — and the illusion shatters 💥

Muggles do not perceive queues, scheduling, or thread blocking. They perceive continuity.

That is why the illusion works.

When the Spell Breaks ⚡

Problems begin when this illusion is treated as a contract.

When it feels like:

This line of code will definitely run after that one.
A DOM change implies an immediate render. (it should… well, not always 🌚)
async guarantees non-blocking UI. (spoiler: it doesn’t 😅)
Fast execution means correct execution. (it works on my local machine 🙃)

These assumptions are intuitive. They are also the root cause of many production bugs.

The Reality Behind the Illusion 🎭

From a wizard’s perspective 🧙‍♀️, there is no magic here — only constraints.

What actually happened:

A muggle interaction placed an event into a queue 📥.
JavaScript was executed when the main thread allowed it 🚦.
A render may have happened — or may have been skipped due to optimization. JavaScript never promised timing ⏱️. The browser never promised visual confirmation 🤝🚫. The illusion was merely held together.

The Event Loop feels “unpredictable” only when the illusion fails. (And we all know exactly how that feels 🫠)

This happens when:

The UI freezes during scrolling.
Animations fail to start.
Promises resolve before the UI updates.
Bugs appear only on low-end devices (the potato phones) or in background tabs.

At that point, the hidden machinery becomes visible.

What muggles perceive as magic, wizards understand as a system of constraints.

Real mastery begins when code is written with these constraints in mind — not against them.
Most bugs start with one silent assumption: that your code controls when and in what order the browser does things.

What’s Next

In the next part, we’ll look at Who actually controls the Event Loop ⚙️ — and why that assumption breaks real applications 💥

Stay tuned 📩🔔👇.

Elina · WebMagic

Mastering the Dark Arts of Web Development