micro task Queue consist of callbacks/resolved functions from fetch, async/await. but why its given more priority then callback queue because sync code is executed first and then afterward async function is executed then why/how microtask queue is given more priority then callback queue ?
I read more about the concept but still confused on it.
2
Answers
Microtask queue more priority because faster.
Sync code run first, then microtask, then callback. Microtask like async/await finish quick. Callback queue slower, used for setTimeout, setInterval.
Microtask make app smooth, no delay. Callback can wait longer. This make app better and faster.
I’ll ignore the qjsengine as I believe this was a typo and will instead answer about the WHATWG’s HTML event-loop concepts.
MICROTASKS ARE NOT BEING GIVEN MORE PRIORITY THAN OTHER TASKS
Too often I see this assertion and it becomes more and more confusing, moreover since now we can tap into the task prioritization system. microtasks just don’t participate at all in this task prioritization system.
Microtasks were introduced in the event-loop design as a way to handle a batch of possibly contradicting modifications made on objects during a script 1 execution. For instance the oldest API we still have that does use this system is the
MutationObserverAPI. Instead of having a lot of JS callbacks fire during another script’s execution, leading to poor performances and possibly hard to debug issues, it collects all the mutations that happened during the script execution, and once the script is over2, it will trigger its notification callback. It could have queued a common task, likesetTimeout()does, but then that would mean that if the script was executed during the update-the-rendering steps of the event-loop (e.g. inside arequestAnimationFrame()callback), you would see the changes on screen before being able to act on it. So the idea of a microtask, that would execute right after the script that spawned it came to life.This design was not only useful for web APIs and when the ECMA group developed the
Promiseconcept, they integrated it directly with the concept of microtask in HTML. SoPromiseswould invoke their callbacks in microtasks too, allowing user-land scripts to perform the same kind of "trigger-at-the-end" operation.3So, yes, there will be a microtask checkpoint when the script execution is done, before any other script can run, simply because that’s what it’s for: execute a callback when the script execution is done.
As I mentioned at the beginning, there is a prioritization system, at the task level4: at the start of an event-loop cycle, the engine will choose one task among all the ones queued in the various task sources. The priority is done by choosing one task source over another.
Even for things like
fetchwhich does expose a Promise based API, the prioritization system can kick in: The returned Promise is going to be resolved in an actual task, which will do only that (related Q/A). So if a UI event occurs at the same time that the fetch operation is done, the browser can say "let’s handle the UI event first". That’s prioritizing.Microtasks on the other hand are forced to run when the current script ends, there is no prioritization.
1. Basically whatever calls prepare to run a script, be it a callback, an actual
<script>, or whatever executes JS2. It’s actually when all currently JS scripts are done running. So if you do synchronously invoke a callback through your script and that callback queues a microtask, the microtask will only execute when your script is done executing, not right after the callback.
3.
async/awaitfunctions being mostly syntax sugar over Promises, they act exactly the same for that matter.4. Tasks are yet another beast than callbacks, they’re purely specs constructs to tell the browser to do stuff, and don’t necessary invoke JS.