Why is there a distinction between microtask and (macro)task in JavaScript?

Question

Conceptually just having one queue for jobs seems to be sufficient for most use-cases.
What are the reasons for having multiple queues and distinguishing those into "microtasks" and (macro)"tasks"?

Answer 1

Having multiple (macro) task queues allows for task prioritization.

For instance, an User Agent (UA) can choose to prioritize a user event (e.g a click event) over a network event, even if the latter was actually registered by the system first, because the former is probably more visible to the user and requires lower latency.
In HTML this is allowed by the first step of the Event Loop's Processing model, which states that the UA must choose the next task to execute from one of its task queues.
(note: HTML specs do not require that there are multiple queues, but they do define multiple task sources to guarantee the execution order of similar tasks).

Now, why have yet an other beast called microtask queue?

We can find a few early discussions about "how" it should be implemented, but I didn't dig as far as to find who proposed this idea the first and for what use case.

However from the discussions I found, we can see that a few proposals needing such a mechanism were on the road:

• Mutation Observers
• Now-deprecated ES Object.observe()
• _{At-that-time-incoming} ES Promises,
• _{Also-incoming-at-that-time-and-I-don't-know-why-it's-cited} ES WeakRefs
• HTML Custom Elements callback

The first two being also the first to be implemented in browsers, we can probably say that their use case was the main reason for implementing this new kind of queue.

Both actually did similar things: they listened for changes on an object (or the DOM tree), and coalesced all the changes that occurred during a job into a single event _{(not to be read as Event)}.
One could argue that this event could have been queued in the next (macro) task, with the highest priority, except that the Event Loop was already a bit complex, and every jobs did not necessarily come from tasks.

For instance, the rendering is actually a part of every Event Loop iteration, except that most of the time it early exits because it wasn't the time to render.
So if you do your DOM modifications during a rendering frame, you could have the modifications rendered, and only after the whole rendering took place you'd get the callback.
Since the main use case for observers is to act on the observed changes before they trigger performance heavy side-effects, I guess you can see how it was necessary to have a mean to insert our callback right after the job which has done the modifications.

---

PS: At that time I didn't know much about the Event Loop, I was far from specs matters and I may have put some anachronisms in this answer.