JavaScript Event Loop & Asynchronous Programming

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