What is microtask starvation, and how can an endless Promise or queueMicrotask chain hurt browser responsiveness?

Direct answer

Browsers perform a microtask checkpoint after a task, and newly queued microtasks can keep extending that checkpoint; an unbounded microtask chain can therefore delay later tasks and rendering even though each individual callback is asynchronous.

Consider a function that calls queueMicrotask(loop) from inside every execution of loop. Each callback is short, but it schedules another microtask before the microtask checkpoint finishes. The browser can remain busy draining microtasks and may not reach the work needed for rendering or user interaction.

Promises can create the same pattern when each reaction immediately schedules another reaction. This is why “put it in a Promise so it does not block” is incorrect. Moving work to microtasks changes ordering; it does not guarantee that the main thread gets time to render.

Use microtasks for short ordering-sensitive follow-up work.
For visual work before a frame, requestAnimationFrame() is usually a better scheduling primitive.
For large CPU work, split the work across tasks or move it off the main thread when appropriate rather than recursively filling the microtask queue.