---
title: 'JavaScript Event Loop & Asynchronous Programming'
source: 'https://youtube.com/watch?v=jzOy07fw2vY'
video_id: 'jzOy07fw2vY'
date: 2026-08-10
duration_sec: 2782
---

# JavaScript Event Loop & Asynchronous Programming

> Source: [JavaScript Event Loop & Asynchronous Programming](https://youtube.com/watch?v=jzOy07fw2vY)

## Summary

This video provides a comprehensive, visual explanation of how JavaScript handles asynchronous tasks while remaining single-threaded. It breaks down the core components—call stack, web APIs, callback queue, and microtask queue—and demonstrates how the event loop orchestrates them to keep applications non-blocking.

### Key Points

- **Core Concept Introduction** [00:02] — The video introduces the event loop as a core concept for every developer, explaining how JavaScript manages asynchronous tasks while remaining single-threaded, with animations and diagrams.
- **Importance of Event Loop** [00:44] — The event loop is one of the most important and misunderstood concepts in JavaScript. Understanding it deeply helps crack front-end interviews and think like a senior developer.
- **Components of the System** [01:45] — The browser or JavaScript runtime includes a call stack, web API environment, task queue, microtask queue, and the event loop, which connects everything together to make JavaScript non-blocking.
- **Call Stack Basics** [02:32] — JavaScript is single-threaded with one call stack that manages execution order. The video demonstrates with a simple example how global and function execution contexts are pushed and popped.
- **Limitations of Call Stack** [04:46] — The call stack cannot handle delays like timers or API calls alone; it lacks the ability to pause or delay tasks, which would block other executions and freeze the application.
- **Web APIs Overview** [06:45] — Web APIs are provided by the browser environment, not JavaScript itself, and include timers, fetch, DOM manipulation, events, storage, geolocation, console, URL, and more.
- **Example with setTimeout** [10:39] — Using setTimeout, the video shows how the callback is registered in the web API environment, the timer runs in the background, and the event loop moves it to the call stack when empty.
- **Event Loop Role** [15:11] — The event loop continuously checks if the call stack is empty and if there are tasks in the callback queue, then moves them to the call stack for execution.
- **Example with Geolocation** [19:10] — The geolocation API example shows how asynchronous work (user permission) is handled outside the call stack, with callbacks going to the task queue and then executed by the event loop.
- **Example with DOM Events** [22:34] — The DOM event example demonstrates how event listeners register callbacks in the web API environment, which are executed when the event occurs, following the same queue and event loop flow.
- **Promises and Microtask Queue** [27:40] — Promises and fetch callbacks go to the microtask queue, which has higher priority than the callback queue. The event loop processes microtasks first.
- **Long Running Task Scenario** [34:54] — When the call stack is busy with long synchronous code, tasks accumulate in queues. After completion, the event loop processes microtasks first, then callback queue tasks.
- **What Goes to Microtask Queue** [38:51] — Microtask queue includes promise callbacks (then, catch, finally), mutation observers, async/await code after await, and queueMicrotask API.
- **Starvation of Function** [41:09] — Starvation occurs when microtasks continuously create new microtasks, preventing callback queue tasks from executing. This is a common interview question.

### Conclusion

The video concludes that mastering the event loop and asynchronous JavaScript is key to cracking front-end interviews and thinking like a senior developer. It emphasizes the importance of understanding the interaction between call stack, web APIs, queues, and the event loop.

## Transcript

which is a core concept that is helpful for every developer to master. Through animations and diagrams, you will learn how JavaScript manages asynchronous tasks while remaining single-threaded.
You will learn the critical differences between the call stack, web APIs, the callback queue, and the high-priority microtask queue. By the end of this video, you will have a visual understanding of how these components
work together to keep your applications running smoothly without blocking. This was created this course. >> Event loop is one of the most important >> Event loop is one of the most important concept in JavaScript and honestly one
of the most misunderstood one. A lot of developer uses asynchronous code every day. Like it could be a promises, it could be observables when
we go with the Angular, it could be a timers, or it could be making the API calls and fetching the data from the server. But when it comes how things actually works under the hood, then things getting confusing. But here is a
reality. If you understood asynchronous JavaScript and event loop in depth, then you are able to crack almost every front-end interview. And the most importantly, you will think like a senior or strong developer who
understand how exactly JavaScript works internally. Now, when we go under the hood, the event loop is just a small part of the bigger system. In the browser or JavaScript runtime, we
stack. We have a web API environment for connecting with outside world. Then we have a task queue, microtask queue, and finally we have event loop, which will
connect everything together. And all of these components works together to make the JavaScript non-blocking, even though it is single-threaded. So, before jumping into the complex
scenarios, let's start from absolute basic. You know that JavaScript is single-threaded. Means we have only one call stack, and this call stack manages the execution order of your program. Now, to
understand the call stack, let me go with very simple JavaScript example. We have console.log with start, then we have a function definition, we are calling the function, and finally, we have console.log for end. And we know
have console.log for end. And we know that before even executing the single line of code, JavaScript creates the memory for all the variables and functions, and it will create the global execution context. That global execution
context is added into the call stack. And now, we have execution of first line. When we execute the first line, we have console.log printed on your
console, then JavaScript will move to the next line. We don't have anything to the function call. When we have a function call, JavaScript creates the new
execution function context, and that is again pushed into the call stack. And now, we have function execution here. So, we have console.log, that is with run, and that is printed on the screen, and we completed our function execution.
As soon as this function execution is completed, the function execution context will be popped out of the call stack. JavaScript will move to the next line and we are done with our script. Here end will be printed in the console
and once we are done the script execution, the global execution context is also deleted from the call stack. And this is how call stack manages the execution order of your program and make sure that only one thing works at a time
in the sequence. Every function call is pushed into the call stack, executed and popped out of the call stack when its execution is completed. Simple,
predictable and perfect for your synchronous code. But here where things getting interesting. This approach work flawlessly when your code run line by line without waiting for anything. But
real life applications are not that much simple, right? What happen when we need to wait for something? We might need to use the timers in your code, you might needs to make the API call or we need to connect
make the API call or we need to connect with different resources, right? And call stack cannot handle that alone. We have only one call stack and its duty have only one call stack and its duty just to execute anything comes inside
it. It does not have ability to pause the task or delay the execution of task, right? And if it had that ability, it could be work on only one long running task and that a task is continuously
executing in call stack, right? And it will basically block the execution of all other task. It could slow down your application or even completely freeze ideal. In web application, we often needs to
connect with the external resources. Like, we might needs to visit any of the server and fetch data from there. We needs to work on updating the DOM by
accessing the different elements. Then, we need to store the data in local we need to store the data in local storage or access it. We might needs to work with timer. It could be a set timeout or set intervals. And we need to
work on promises, right? We can make the API call, fetch the data, and in that between need to wait for getting the response. Or you might needs to work on event. We can have a button and add the event on that. And on click of that
event on that. And on click of that button, something will execute. And to handle all of those task, JavaScript relies on additional superpower that is relies on additional superpower that is present outside call stack. And we will
get all of those superpower through web APIs. Now, let's understand what are the web APIs. Web APIs is functionality provided by
the browser environment or JavaScript runtime, but not by JavaScript itself. runtime, but not by JavaScript itself. Web APIs provide set of interfaces that allow you to connect with external resources. Which includes timer,
resources. Which includes timer, network request, DOM manipulation, user events, storing the data in the browser, and much more. And we have a number of APIs available. We will discuss few of the most important one. And the first
one is timer. It is used for scheduling the execution. We can have the set timeout, set interval. We can access those APIs through timer web API environment. And that is mainly used for delaying some execution. Then we have a
next web API that is related to HTTP or network request and that is fetch. We are using fetch for calling the backend services. To accessing the DOM elements, we are using different DOM APIs. It could be
document.getElementById, createElement, append child and all those functions we can access through DOM APIs for updating our UI
dynamically. Next, we have event APIs. We need to add some event listener on any of the element and we are accessing those functions through event APIs. Apart from that, we have some important APIs related to storage. We need to
access the local storage, session storage and for storing the data in the browser, we need to use the storage APIs. We might need to access user current location. For this purpose, we have geolocation APIs. Then we are using
console.log, right? And that is part of console API. We might need to hit some URL and fetch some data from the server, right? And for that we are using URL
API. We have few more related to media or canvas, or canvas, web sockets, web workers and all those API help us to connect with the external world and get required functionality in
the browser or JavaScript code. And whatever you are seeing here, whether it is timer, fetch, multiple events APIs, console, URL,
those are part of web API environment. That is not part of core JavaScript. Most of the people think that this web APIs is part of the JavaScript, but that
is not true. Since this web APIs are provided by the browser, we can directly provided by the browser, we can directly use them into browser or JavaScript code use them into browser or JavaScript code through global or window object. Now, we
understood how exactly the synchronous code work in JavaScript line by line, and we also understood what are the different web APIs. But, we still have
very important questions. How exactly JavaScript handle the delay or asynchronous code executions, right? And this is where some of the web APIs play a key role. They help in handling these
operations outside the call stack, so that JavaScript can remains a non-blocking and continue executing other code. Now, let's start with very simple example, and we will understand how exactly delay handle in JavaScript
how exactly delay handle in JavaScript by using the timer web APIs and using the set timeout function. We are starting with console, then we have a set timeout. It will take the callback function with a delay of 4 second, and
then we have console.log at the end of the script. And we know that what will be the output, right? First, we will have the start here, then this callback function will needs to wait for 4 seconds, so JavaScript move to the next
line. It will print the end, and after 4 second delay, it will print the callback. So, output will be start, end, and callback. But, we will understand and callback. But, we will understand how exactly things works under the hood.
We know that before starting even single line of code, JavaScript creates global execution context, and that execution context is added the call stack. And in context is added the call stack. And in this code we are using couple of web
APIs, right? The first one is console and the second one is a timer API for set a timeout. So, we will list down those two APIs here. And now JavaScript
started execution with line number one. We have console here, so JavaScript We have console here, so JavaScript delegate this to console web APIs. It will execute that particular console.log statement and it will print start on
console. Now, we move to the next line and on next line we have a set timeout. We will required one more web APIs and this set required one more web APIs and this set timeout will be delegated to timer web
APIs. Now, it's responsibility of the timer web APIs to handle next thing. It will register the timer, store that callback function along with registered
timer. Here, we are seeing the callback function and that function will be passed as a first parameter to your set timeout. Here, I'm using the arrow function and we don't see any callback
name, but you can consider name of this function as a callback. Hope you are clear till this point. Now, this callback function is registered in the web API environment and this timer is also started countdown. But, we know
that call stack cannot wait for anything. If it's waiting for this timer to execute, then we are not able to handle other task. So, JavaScript and call stack will move to the next line. Again, we have console.log statement, so
internally this console web APIs will be called and it will print end on console. We are done with our script execution and as soon as script execution is and as soon as script execution is completed, this global execution context
will be popped out of the call stack. Meanwhile, this timer is still running in the background. It is counting down from 4 3 2 1 till 0. As soon as these 4
seconds are completed, this callback function is ready to execute. But now, here is important part. We know that everything in JavaScript is executed
inside call stack. So, somehow this callback function needs to come back into the call stack to start its execution. And once it reaches to call stack, the job of the call stack is simple, just to quickly execute that
simple, just to quickly execute that function and print this on console. And now, we have one very big question. How exactly this callback function will get exactly this callback function will get back into the call stack and where
exactly the callback queue and event loop comes in picture. Once the timer is completed and this callback function is ready for execution, it cannot directly
go into call stack because in call stack, we might be doing some another task and if this callback function directly added, it could disturb the existing task that is already running in. So, it needs to follow the different
approach and here now we have task queue and event loop comes in picture and play a very important role. Once this function is ready for execution, now it will go to the callback queue. We will see this is
added into the callback queue and job of the event loop starts from here. The event loop continuously check for two things. The first one is the call stack and the second one is this task or callback queue. And once it see the call
stack is empty, it will check if we have anything in callback queue for execution. And if we have anything, it will it quickly pick it and add that into the call stack. In our case, this callback function sits
in task or callback queue. The event loop detects it and move this callback function into call stack. And now this callback function start executing.
Internally, the execution context will be created for this callback function, and actually that callback function execution context run in call stack. Call stack quickly execute it. The call stack is empty now, and this callback is
printed on the console. Hope you are clear with this first example. The event loop play very important role, and its main job is to
check for this callback or the task queue. And if we have anything for execution, add that into the call stack. The responsibility of the event loop is
very simple, but really important. We will understand that with the help of simple visual. Here we have three different task waiting in callback queue. The event loop continuously check if call stack is empty or not. In our
case, the call stack is empty, and nothing is currently executing. It will pick first task from callback queue. See here. The first task will be picked by
the event loop and added into the call stack. Now that task is executing. Once that task is completed, the call stack is empty again. But what if something is
already running in call stack? Like we have global execution context and we could have couple of function execution context that is already present in the call stack. And we have something waiting in callback queue as well. In
this case, the event loop wait patiently. It will not interrupt or push any task into call stack. It will wait until all the task from the call stacks
until all the task from the call stacks are completed. And once call stack is empty, again it is active now and it will pick the next task from the callback queue and add into the call stack. That the task is executing now.
Once that task is executed, call stack is empty again and event loop again check if the call stack is empty. In our case, it is empty. Now, it will pick case, it is empty. Now, it will pick task three and add that into the call
stack. And once that task execution is done, the call stack is empty now and our callback queue is also empty. That means all our execution is completed.
And this is how the event loop play very important role and acts as a bridge important role and acts as a bridge between your queues and call stack. Key rule, event loop never add any task into the call stack until call stack is
completely empty. And this is how entire flow works together making JavaScript behave asynchronously even though it is single-threaded synchronous programming language.
Now, to strengthen our concept more, let's go with another example. And in this example, we will understand one more web APIs and that is geolocation
more web APIs and that is geolocation services. We have very simple code here. We are using geolocation service and through which we are trying to get the current location of user. If user approve it, we will get current
position. If user deny it, we will get error. So, let's start with first step. Before executing any line of code, JavaScript create global execution context and that is added into call stack. And for this code we are using
two web APIs. First one is geolocation and second one is console. So, both APIs are listed here. Then, we will start the execution of first line and this get
current position method added into the call stack. JavaScript see this method is belongs to web API. So, JavaScript does not execute it by itself. It hand does not execute it by itself. It hand over this request to geolocation API.
Then, this get current position method is executed by geolocation APIs and then browser start the asynchronous work. It will show this kind of modal in the will show this kind of modal in the browser and it will ask for user's
permission. It will ask you for the GPS or the location. Meanwhile, call stack will continue do its execution, right? It see like this particular function is passed to web API, so it will move to the next line and here your code
execution is completed. So, global execution context will be popped out of the call stack and the call stack is empty now. Then, we don't know how much time user will take to give this permission, right? It can give it
immediately or even he can reject it. He don't want to share his current location. Here, we have two possibilities. Either user allowed to possibilities. Either user allowed to visit the site or user can deny it. And
based on two possibilities, we can have two different options here. If user allowed to visit the site, the position callback will be ready. And if user deny it, then we have error callback. For now, I'm showing both the callbacks
here. We have one position callback that is for positive case and error callback for negative case. And you will see that pop up is gone now. For now, let's go
with only positive scenarios. Consider user click on allow to visit the site. user click on allow to visit the site. And now we have position callback ready. Then it will follow the similar step. First, it will go to task queue. If you
see here, it is going to the task queue. And now this position callback will wait in the task queue until event loop picks it. Now we have event loop that comes in action and it is active now. And it will see we have a empty call stack. So it
will pick this position callback and add that into call stack. And the call stack quickly execute it. Once that execution is done, the call stack will be empty
now. And user current location will be displayed in the console. Hope you are clear with second example. Now, let's go with one more example and that will help you to understand asynchronous JavaScript in much better way. In third
example, we will go with two more web APIs and that is related to DOM and event. The example here is very simple. We will start with console.log. We will end with console. And in between, we just have one button in the browser. We
will get that button reference by using document.getElementById document.getElementById and add event listener on it. And when user click that button, we will just console button clicked message. Very
simple example and it will follow the similar approach, but we just going with similar approach, but we just going with the different web APIs. When JavaScript start executing, the global execution context is added into the call stack and
then we have a first line here. We have console here, so console web API comes in picture and it will print start on the browser console. Then JavaScript see
the browser console. Then JavaScript see we are using document.getElementById. This is present from the DOM web API and which is used to get the button reference. And then it will simply stored the
reference of this HTML element into this button variable. Now we will move to the next line. Again, we have that button and we are adding add event listener on
it. This add event listener will be present from the event APIs and it will register a callback function in the web API environment. Here I'm using arrow function, but now you can consider this as a named
function with name callback. Important point here, this callback is not executed it. It is just a registered. This will execute when user click on
this button and we don't know when user will click on this button. So JavaScript will continue its execution and now it will go to next line. This is the last line of our script, so it is executed.
It will print end in the console and this global execution context will be popped out of the call stack. So that is happening. We have call stack empty and end is printed here. Now we are done with the script
execution and this callback function will sit in web API environment waiting will sit in web API environment waiting for user to click on this button. So, what will happen when user click on this button? This callback function is ready
to execute. It simply comes into callback queue. So, let's see. Here user clicks on button. The callback function is ready for execute and it is come into the callback queue. And event loop will be active
now. It will see we have a empty call stack and we have something to execute stack and we have something to execute in callback queue. So, it will pick this in callback queue. So, it will pick this task and add into the call stack. This
task is added into the call stack. It will execute now and once its execution is done, we have console.log statement that is printed on console and then we
have a empty call stack. See here. Our function execution is completed. So, we have empty call stack. We have empty call back queue and this button clicked will be printed on console. Hope you are clear with this third
example as well. Till now we have seen three different examples. The first one is with set time out. The second one is with geolocation API and third one is with user events. Even through they look different, but
underlying they follow the similar approach. In every cases, the callback is registered in the web API environment and once that callback is ready for and once that callback is ready for execute, it comes to callback queue and
then event loop picked it if call stack is empty and then it is executed. In simple word, call stack execute all your code. Web APIs are used to connect
with external world and they handle your a-sync code through callback queue. And then we have event loop that connects everything together. If you understood all of these three examples and following along with me and
get idea around how this flow work, you already mastered how asynchronous JavaScript works. But wait, we have few more things to But wait, we have few more things to discuss. And those are very important.
Till now everything looks quite straightforward. Task goes to Web APIs. From Web APIs it is going to callback queue and from callback queue it again comes to call stack. But when it comes to promises or fetch
But when it comes to promises or fetch API call, things work little differently and more interestingly. To fully understand the difference, now let's go with one more example. In this example, we will go with fetch API call
and along with that we will discuss set time out as well. time out as well. We will see how those things are differ from each other. In this example, we are using three Web APIs. The first one is
console, the second one is timer and third one is fetch. So, all the three Web APIs are listed here. The console is for console.log, then timer is for set
timeout, and then fetch API for network request. And we know that initially our call stack is a empty and before executing the single line of code, JavaScript creates global execution context and
that execution context is added into the call stack. Now, the script execution is started. We are on line number one. Here call stack see like this is console.log
and this request is delegated to console web APIs and it will basically print that start on your console. On next line, we have set timeout. So, JavaScript again delegate this set time
request to timer APIs and we know that when we have set timeout, the callback is registered in the web API environment and attached with its timer. So, in this
case, we have this particular callback and that is executed after 4 seconds. So, this callback will be registered in the web API environment and timer is attached to it. You can consider name of this callback as a CBT, that is callback
timer. Then, JavaScript will not wait for anything, like it will directly move to the next line and now we have next web API, that is fetch. We're making the API call for some dummy request here and it will make the network request and
fetch the necessary data for us. This fetch will return promise and then we're attaching dot then to it. So, call stack delegate this network request to web API. So, you will see new callback is
registered in the web API environment and I'm giving name as a CBP, that is callback promise. And here browser started fetching data in the background. So, we will move to the next line and we have last line of
our script, that is end. Once this line is executed, our script execution will be completed. This end will be printed on console and this global execution context will be popped out of the call stack. So, if you see here, the global
execution context is popped, call stack is empty now and the end is printed on is empty now and the end is printed on the console and our script completed here. Now, at this point we have two callback
registered in the Web API environment, right? The first one is CBT, that is right? The first one is CBT, that is waiting for timer to finish, and then we have a CBP, that is waiting for promise to resolve. Once promise is resolved,
this callback function will be ready for execution. And once timer is finished, this CBT function will ready for execute. Consider this API call is taking more time, and meanwhile this 4-second timer
is finished. And we know what will happen in this case, right? This CBT function is ready for execution. It is pushed into the callback queue. Then event loop see if we have empty call stack, and it pick that function, and
that function is quickly executed. This is simple and straightforward. We are clear with that now. But here we have now interesting question. What happen
when that promise get resolved? And which function, that is CBT or CBP, gets which function, that is CBT or CBP, gets executed first? Now, consider this API call is very fast. It will return us the result in few milliseconds.
And in this case, the promise is resolved, and this CBP function is ready for execution. Still the timer is continue running, and it's needs to complete 4 seconds. So, question is what will happen with this
question is what will happen with this CBP function? Does it added to callback queue, same as a timer or geolocation API? No. This CBP function now goes into the different queue, and that queue is
micro-task Q. Things are interesting, right? right? This micro-task Q is similar as a callback Q, but having higher priority. And when it comes to event loop, event
loop pick the task first from micro-task Q and then it will go to callback Q. In empty. And now this CBP function is ready for
execution. So, it will directly go to micro-task Q. It is waiting there. Then event loop comes in action. It will check if we have empty call stack. In
this case, we have empty call stack. So, it will pick that CBP callback from it will pick that CBP callback from micro-task Q and add that into the call stack. And job of call stack is very simple. It
will quickly execute it and once executed, we have data received printed Simple. Clear, right? And meanwhile, this CBT
function still waiting this timer to complete, right? Suppose this timer is complete, right? Suppose this timer is completed after 4 second. Now, this CBT function is ready for execute and it will follow its traditional path. It
will go to callback Q. Now, it is coming to callback Q. Again, event loop comes in action and it will see we have empty call stack and it will pick this CBT
call stack and it will pick this CBT function and add into call stack. And call stack quickly execute it and inside set timeout will be printed on console. set timeout will be printed on console. And this is how things works together.
Hope you are clear with that. The callback function attached to promise will follow the micro task queue approach and all other web APIs we
discussed till now, those are going to callback queue. Micro task queue is always having higher priority than the callback queue. Now, understand one more scenarios. In line number 10, our code is executed. The set timeout and fetch
callback registered in the web API environment, but from line number 11, right? We have long running code here. Suppose we have large amount of code and
call stack is now busy with that executing long running task. While this call stack executing long running task in the background, the API call will be made and this data will be fetched. So, promise is resolved and then now this
CBP function is ready for execute. So, it will follow its traditional approach and it will go to micro task queue. Still call stack is busy. It's doing its work. So, this CBP function needs to
wait in micro task queue because event loop will only pick task in the queue if call stack is empty. And in this case, the call stack is continuously executing
the call stack is continuously executing some synchronous long running code. The call stack is continue working and meanwhile this 4 seconds also completed. This CBP callback is now ready for execute and again it will follow its
traditional approach and it will come to callback queue. Now, we have task in both the queues and the meanwhile call stack is still doing the execution of long running synchronous task. We don't know how much code we have. It
could be millions of line of code, right? And call stack is currently busy with that. Suppose now this long running task is completed, so code will move to the next line. This is the last line in our code. And once this line is
completed, this global execution context will be deleted from the call stack and will be deleted from the call stack and this console.log end will be printed on console. If you see here, call stack is empty now and end will be printed in
console. And now event loop comes again in action. It will check if we have empty call stack. In this case, yes. So first it will pick the task from micro task queue because it's having higher priority. So CBP callback will be picked
priority. So CBP callback will be picked by event loop and pushed into the call stack. Call stack quickly execute it. Once the execution is done, we have empty call stack and this particular string will be printed on console. Now
event loop again check if the call stack is empty and if we have anything in micro task queue. Right now we don't have anything to execute in micro task queue, so it will go to callback queue. And then it will pick this CBT callback
and push that into the call stack for execution. Call stack quickly execute that CBT callback and inside set timeout will be
printed on console. Now we have empty call stack and empty callback queue. And this is how things work. When we have very long running task, the call stack first will finish all the synchronous code and meanwhile we can
have multiple task in micro task queue or callback queue and once all the synchronous code execution is done, the task from the micro task queue and callback queue will be picked by event loop. And here again the higher priority
will be given to microtask queue and then callback queue. This is how asynchronous JavaScript works. Hope you are clear with all the
details now. Now, we have few more questions. As we have two queues, one is callback queue or task queue, and another one is microtask queue, right? And microtask queue is having higher priority. So,
what all thing will go to microtask queue? And answer is simple. There are microtask queue. The first thing, any callback function
attached to promises. It could be dot then, dot catch, or finally. Any callback function present in promise chaining will go to microtask
queue. Second thing is mutation observer. The mutation observer is again the API provided by the browser in JavaScript that let you watch for changes in the DOM. And then it will run the callback function when those changes
the callback function when those changes happen in the DOM. Then we have async await, right? So, whatever code or the function body we have after await keyword, that is go to microtask queue. And finally, we have queue microtask.
This is again one of the web API provided by the JavaScript, and it will provided by the JavaScript, and it will help you to run function as a microtask. So, those four things will go to microtask queue. And apart from
anything, any callback that we discussed till now, all will go to callback queue or task queue. Whether it is a timer, geolocation, geolocation, managing the events, and any
asynchronous operation, everything will goes to task queue. And understanding this difference is very important because when we have output base question, understanding what things will go to micro task queue and what things
will go to callback queue is very important. Based on that, our output important. Based on that, our output will be changes. I hope you have solid understanding around the asynchronous JavaScript now.
How call stack works, what are web APIs, what is task queue or callback queue, what is micro task queue, what is event loop, when event loop comes in picture
and what different things will go to callback queue and micro task queue. Finally, before ending this video, let's understand one more very important
understand one more very important concept and that is asked again in most of the interviews and that is starvation of function. We have two queues, right? The one is callback queue and one is micro task
queue. And event loop give higher priority to micro task queue. First, it will finish all the task in micro task queue and then it will pick the task
from callback queue. Suppose if event loop pick first task, Suppose if event loop pick first task, right? The task one is now executed. Now, call stack is empty. Again, event loop will pick second task from the
micro task queue, that is task two. Now, this task will go to call stack and it started execution. And what if this task two will create
another task? It is possible, right? Might be task two is having some API Might be task two is having some API related code or it's using some mutation observer or it having a Q task logic. Suppose this task two is executed and it
created one more task, that is task four. Now, this task four will go to web API environment and might be it is quickly finishes making the API call, right? And this task four is now ready for
execution. Again, this task four will come to microtask queue. And meanwhile, your task two is still executing. Now, task two execution is executing. Now, task two execution is completed and we have empty call stack
and it will pick task three now. Task three execution is started and what if task three will create another microtask? This is possible, right? This could go in infinite loop. We don't know what will happen in this code, right?
And if create one more task, that is a task five, you again it will come to microtask queue and this cycle will continue. In this case, the event loop always give higher priority to microtask queue, right? And then whatever task is
present in the callback queue, they need to stay for longer time and that is to stay for longer time and that is starvation of function. At the end, this task is callback function, right? And this task are waiting in the callback
queue for long time because we have multiple things in the microtask queue and those are continue in the cycle. And in this case, this function needs to wait and this is called starvation of function. This is a very important
interview question and ask in most of the front-end interviews. You should be clear, right? When we have multiple things in microtask queue, the callback queue will not get chance to execute. Suppose now this task three is completed
and we have empty call stack. In this case, the task four will get chance from micro task queue and once we have empty call stack and empty micro task queue, then and then the task in the callback
queue will be executed. Now, task one is executed, then task two will execute. Meanwhile, if you get anything in micro task queue again, that will get higher priority and then task three needs to wait until micro task queue will be
empty. Here, task two will be completed and then task three will get chance and once the execution stop, our call stack and both the queues are empty now and this is how things work. Starvation of
function, very important concept. In our previous video, we already seen how exactly call stack will be visible in the browser, right? We see how the global execution context or function execution context is added into the call
stack, right? But showing how callback queue or micro task queue or event loop works, that is at least not possible in the browser till now. Those are internal things to the browser and handle internally and that is not
exposed on the dev tool or we don't have any way to directly visualize it. Hope you are clear with all these details. Finally, I think
that's all for this video. We have covered lots of interesting content and if you understood those properly, you are able to crack almost every front-end
interview, at least for asynchronous code changes. That's all for this video. Thank you for watching. If you are enjoying my content, I request you to like it. Please share this beautiful content with your friend, so it will
reach to more people. If you have any questions, do comment me and I will questions, do comment me and I will answer as soon as possible. And finally, subscribe to channel for getting latest video notification. Thank you for
watching and see you in next one. Till now, thank you. Bye.