Callback Queue vs. Microtask Queue
In my previous article JavaScrip “Asynchronous” Nature Unmasked! I dove into the rabbit hole of JavaScript under the hood. Unsurprisingly the more I learned the more questions I had, thus here we are diving in a bit deeper.
In this article I’ll be going over how event looping and queues play an important roll in the order of execution in JavaScript. If what I’m saying or about to say seems a little confusing, I urge you to take a look at my pervious article where I went over some the foundational knowledge we need before we move on.
Some background information on Fetches in JavaScript:
Fetch is a built in tool of AJAX that allows us to send and receive information from our backend using JSON(JavaScript Object Notation). Fetch is also a web browser feature just like .setTimeout(). JSON is language agnostic, however it resembles objects in JavaScrip because it has key:value pairs. AJAX stands for Asynchronous JavaScript And XML(Extensive Markup Language). Simply put we are now able to communicate between our front and backend using a language that JavaScript is familiar with.
Fetch itself is a function invocation that return to us a promise. It uses a URL as its first argument and that’s where it will get/send information to/from. The promise has a few built in methods. One most commonly used method is .then() which takes in a callback. When we first get a response back from our fetch it needs to first be converted into JSON using the .json() method and then we can use the JSON to work with our data. For these two steps we need do use the .then() method twice. Heres an example to clear up any confusion:
Now that we have a better understanding of Fetch let’s see how it works under the hood.
We know that when JavaScript uses a web browser feature the execution is handed off to the browser and JavaScripts Tread of Execution (TOE) continues on to the next line of code. In this time the web browser executes the code and then pushes the output into the Callback Queue, where there is an event loop that continuously checks to see if the call stack is empty and if the global code is finished running. But as you have noticed from the title of this article we actually have more than one Queue! The programmers behind JavaScript realized that not all deferred functionality are created equal. Typically promises hold more important data, thus it has importance than time functionality so to have all the deferred functionality waiting in the same Queue could be a bit of a pain. Therefore the creation of the MicroTask queue.
When you run the following snippet of code you get the console logs in an unexpected order:
In the above example we use Promise.resolve() to mimic what would happen when we get back data from our Fetch. Blow I will show execute the same code but instead use a callback function or arrow function for cleaner code that will give us the same results.
This is how JavaScript executes the following code:
First you have the Global code pushed to the call stack, when thats finished the output in the Microtask Queue gets pushed into the call stack and once the Microtask Queue is empty, the outputs in the callback Queue gets pushed to the call stack.
Not convinced? I wasn’t either that’s why I tried the following block of code to see how well each Queue is at maintaining order:
It’s clear from the code above that the output from the resolved promises are pushed onto the call stack before the output of setTimeout. Furthermore, each Queue maintains the order in which it receives the output from the bowser. Because our setTimeout1 had a timeout of 1000 milliseconds it was the last to go into the Callback Queue from the web browser and thus last to be pushed onto the call stack. Similarly our promise outputs were pushed onto the call stack in the order it was sent to the browser and Microtask Queue.
As I’ve mentioned before the more you learn the more you realize how much learning there is left. If you’re in the world of tech this should just be used as motivation to dig deeper!
