When “Soon” Never Comes: Understanding Microtask Starvation in JavaScript

There’s a promise in JavaScript that feels reassuring.

You schedule something, and you expect it to run.

Maybe not immediately—but soon.

And most of the time, that’s true.

Until one day, something quietly breaks that expectation.

A timer never fires.

The UI stops updating.

The system feels stuck—

even though nothing has crashed.

The Invisible Priority

JavaScript doesn’t treat all asynchronous work equally.

Some tasks are allowed to wait.

Others are not.

Microtasks belong to the second group.

They are designed to run immediately after the current execution finishes.

Not later.

Not eventually.

But as soon as possible.

A Rule That Changes Everything

After any piece of JavaScript completes, the engine does something very specific:

It processes all microtasks before moving on

Not one microtask.

Not a few.

All of them.

And this is where things begin to shift.

A Loop That Never Ends

Consider this:

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

loop()

Each microtask schedules another.

And because the system must finish all microtasks before continuing—

it never leaves the microtask phase.

The queue is never empty.

And so the system never moves forward.

What Gets Left Behind

Now imagine there’s a timer:

setTimeout(() => console.log("Hello"))

It’s ready.

It’s waiting in the macrotask queue.

But it never runs.

Because the system never reaches it.

The microtasks keep coming.

And they always go first.

Not a Bug—But a Consequence

This behavior is not accidental.

Microtasks were designed to handle immediate follow-up work:

• resolving promises
• continuing async operations
• finalizing internal steps

They are meant to complete quickly.

But when they don’t—

when they keep scheduling more work—

the system has no way to interrupt them.

The Starvation Effect

This creates what is known as microtask starvation.

Not because the system is frozen.

But because one kind of work dominates completely.

Everything else waits.

Indefinitely.

A System Without Fairness

JavaScript guarantees order.

But it does not guarantee fairness.

If microtasks keep arriving, they will always be processed first.

There is no mechanism that says:

“Enough. Let something else run.”

And so the responsibility shifts to you.

Breaking the Cycle

Avoid patterns that endlessly schedule microtasks.

Be cautious with recursive promise chains.

And remember that even something that feels lightweight—

can become overwhelming when repeated without pause.

Sometimes, the solution is simply to step back.

To allow the system to breathe.

A Subtle Lesson

Microtask starvation reveals something deeper about JavaScript.

It’s not just about what runs.

It’s about when the system is allowed to move on.

And if you prevent that transition—

intentionally or not—

you can create a system that is always busy,

but never progressing.

A Final Thought

In JavaScript, “soon” has a very specific meaning.

It means:

“Before anything else happens”

And if that “anything else” never gets its turn,

then “soon” quietly becomes…

never.