Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated: 1 1 00:00:01,240 --> 00:00:04,870 So, we learned what AJAX and APIs are. 2 2 00:00:04,870 --> 00:00:07,993 We used a bunch of asynchronous code already 3 3 00:00:07,993 --> 00:00:11,150 and we learned all about promises. 4 4 00:00:11,150 --> 00:00:14,810 But what's missing is to finally understand how all 5 5 00:00:14,810 --> 00:00:18,278 of it really works behind the scenes of JavaScript. 6 6 00:00:18,278 --> 00:00:20,093 And so let's find out. 7 7 00:00:23,109 --> 00:00:26,090 And to start let's quickly review the JavaScript runtime 8 8 00:00:26,090 --> 00:00:29,380 that we talked about way back in the course, 9 9 00:00:29,380 --> 00:00:32,680 just to make sure that the rest of this lecture will make 10 10 00:00:32,680 --> 00:00:33,513 sense to you. 11 11 00:00:34,450 --> 00:00:38,810 So, a JavaScript runtime is basically a container 12 12 00:00:38,810 --> 00:00:41,200 which includes all the different pieces 13 13 00:00:41,200 --> 00:00:44,838 that are necessary to execute JavaScript code. 14 14 00:00:44,838 --> 00:00:49,838 Now, the heart of every JavaScript runtime is the engine. 15 15 00:00:50,230 --> 00:00:53,690 So, this is where code is actually executed 16 16 00:00:53,690 --> 00:00:57,070 and where objects are stored in memory. 17 17 00:00:57,070 --> 00:00:59,960 So, these two things happen in the call stack 18 18 00:00:59,960 --> 00:01:00,973 and in the heap. 19 19 00:01:01,820 --> 00:01:04,170 Now, what's important to note here is 20 20 00:01:04,170 --> 00:01:08,200 that JavaScript has only one threat of execution. 21 21 00:01:08,200 --> 00:01:11,560 And so it can only do one thing at a time. 22 22 00:01:11,560 --> 00:01:14,810 There is absolutely no multitasking happening 23 23 00:01:14,810 --> 00:01:17,170 in JavaScript itself. 24 24 00:01:17,170 --> 00:01:20,960 Now, other languages like Java can execute multiple pieces 25 25 00:01:20,960 --> 00:01:24,963 of code at the same time, but not JavaScript. 26 26 00:01:24,963 --> 00:01:29,963 But anyway, next we have the web APIs environment. 27 27 00:01:30,610 --> 00:01:34,050 These are some APIs provided to the engine, 28 28 00:01:34,050 --> 00:01:36,567 but which are actually not part of 29 29 00:01:36,567 --> 00:01:38,773 the JavaScript language itself. 30 30 00:01:40,510 --> 00:01:42,800 So, that's things like the DOM timers 31 31 00:01:42,800 --> 00:01:47,800 the fetch API, the geolocation API, and so on and so forth. 32 32 00:01:48,740 --> 00:01:51,630 Next up, there is the callback queue 33 33 00:01:51,630 --> 00:01:54,900 and this is a data structure that holds all the ready 34 34 00:01:54,900 --> 00:01:58,480 to be executed callback functions that are attached 35 35 00:01:58,480 --> 00:02:00,793 to some event that has occurred. 36 36 00:02:01,650 --> 00:02:04,800 Finally, whenever the call stack is empty 37 37 00:02:04,800 --> 00:02:08,220 the event loop takes callbacks from the callback queue 38 38 00:02:08,220 --> 00:02:12,710 and puts them into call stack so that they can be executed. 39 39 00:02:12,710 --> 00:02:14,900 So the event loop is the essential 40 40 00:02:14,900 --> 00:02:18,070 piece that makes asynchronous behavior possible 41 41 00:02:18,070 --> 00:02:19,660 in JavaScript. 42 42 00:02:19,660 --> 00:02:21,640 It's the reason why we can have a 43 43 00:02:21,640 --> 00:02:25,170 non blocking concurrency model in JavaScript. 44 44 00:02:25,170 --> 00:02:29,320 And a concurrency model is simply how a language handles 45 45 00:02:29,320 --> 00:02:32,840 multiple things happening at the same time. 46 46 00:02:32,840 --> 00:02:34,510 But now how does this 47 47 00:02:34,510 --> 00:02:37,860 non blocking concurrency actually work? 48 48 00:02:37,860 --> 00:02:41,370 And why is the event loop so important? 49 49 00:02:41,370 --> 00:02:43,053 Well, let's find out. 50 50 00:02:44,950 --> 00:02:49,460 And let's focus on the essential parts of the runtime here. 51 51 00:02:49,460 --> 00:02:53,650 So, that's the call stack the event loop the web APIs 52 52 00:02:53,650 --> 00:02:55,620 and to callback queue. 53 53 00:02:55,620 --> 00:02:59,650 So, as you know, by now, a JavaScript engine is built 54 54 00:02:59,650 --> 00:03:02,720 around the idea of a single threat. 55 55 00:03:02,720 --> 00:03:06,860 But if there was only one thread of execution in the engine 56 56 00:03:06,860 --> 00:03:09,890 then how can asynchronous code be executed 57 57 00:03:09,890 --> 00:03:11,960 in a non blocking way? 58 58 00:03:11,960 --> 00:03:14,490 Well, that's actually the big question 59 59 00:03:14,490 --> 00:03:16,483 that we're gonna answer in this video. 60 60 00:03:17,370 --> 00:03:19,240 So, essentially you will learn 61 61 00:03:19,240 --> 00:03:22,450 how the JavaScript concurrency model really works 62 62 00:03:22,450 --> 00:03:25,480 behind the scenes, using all the parts of the 63 63 00:03:25,480 --> 00:03:28,630 JavaScript runtime that you already know. 64 64 00:03:28,630 --> 00:03:31,170 And as always, we will do this by looking 65 65 00:03:31,170 --> 00:03:33,780 at a real code example. 66 66 00:03:33,780 --> 00:03:35,730 So, let's walk through the code line 67 67 00:03:35,730 --> 00:03:40,009 by line and I will keep updating the call stack as we go, 68 68 00:03:40,009 --> 00:03:43,720 however, you already know how to call stack works. 69 69 00:03:43,720 --> 00:03:46,030 And so it's best that you focus more 70 70 00:03:46,030 --> 00:03:50,258 on the code and on the web APIs and callback queue. 71 71 00:03:50,258 --> 00:03:55,150 Okay, but now let's start by selecting this image element. 72 72 00:03:55,150 --> 00:03:56,800 And then in the next line 73 73 00:03:56,800 --> 00:04:01,643 we set the source attribute of that image to dog.jpg. 74 74 00:04:02,540 --> 00:04:06,250 And as we learned before this will now start to load 75 75 00:04:06,250 --> 00:04:10,040 this image asynchronously in the background. 76 76 00:04:10,040 --> 00:04:12,520 But this time we can actually understand 77 77 00:04:12,520 --> 00:04:15,955 what that mysterious background actually is. 78 78 00:04:15,955 --> 00:04:20,084 So, as you already know everything related to the DOM 79 79 00:04:20,084 --> 00:04:25,084 is not really part of JavaScript, but of the web APIs. 80 80 00:04:25,890 --> 00:04:29,100 And so it's in a web APIs environment where 81 81 00:04:29,100 --> 00:04:33,600 the asynchronous tasks related to the DOM will run. 82 82 00:04:33,600 --> 00:04:38,200 And in fact, the same is true for timers AJAX calls 83 83 00:04:38,200 --> 00:04:41,630 and really all other asynchronous tasks. 84 84 00:04:41,630 --> 00:04:45,440 So, again, these asynchronous tasks will all run 85 85 00:04:45,440 --> 00:04:48,443 in the web API environment of the browser. 86 86 00:04:49,360 --> 00:04:53,170 Now, if the image would be loading in a synchronous way 87 87 00:04:53,170 --> 00:04:56,280 it would be doing so right in the call stack 88 88 00:04:56,280 --> 00:05:00,090 blocking the execution of the rest of the code. 89 89 00:05:00,090 --> 00:05:03,970 But, as we already learned, that would be terrible. 90 90 00:05:03,970 --> 00:05:08,640 And that's why loading images in JavaScript is asynchronous. 91 91 00:05:08,640 --> 00:05:11,560 So it does not happen in the call stack. 92 92 00:05:11,560 --> 00:05:14,900 So, not in the main thread of execution, 93 93 00:05:14,900 --> 00:05:17,600 but really in the web APIs environment 94 94 00:05:17,600 --> 00:05:18,903 as I mentioned before. 95 95 00:05:19,780 --> 00:05:22,700 Now, if we want to do something after the image 96 96 00:05:22,700 --> 00:05:24,230 has finished loading, 97 97 00:05:24,230 --> 00:05:27,150 then we need to listen to the load event. 98 98 00:05:27,150 --> 00:05:31,600 And so that's exactly what we do in the next line of code. 99 99 00:05:31,600 --> 00:05:33,780 So, here we attach an event listener 100 100 00:05:33,780 --> 00:05:36,520 to the load event of that image 101 101 00:05:36,520 --> 00:05:39,193 and pass an a callback function as always. 102 102 00:05:40,060 --> 00:05:43,610 In practice, this means to register this callback 103 103 00:05:43,610 --> 00:05:46,060 in the web APIs environment, 104 104 00:05:46,060 --> 00:05:48,970 exactly where the image is loading. 105 105 00:05:48,970 --> 00:05:51,000 And to callback will stay there 106 106 00:05:51,000 --> 00:05:53,456 until the load event is emitted. 107 107 00:05:53,456 --> 00:05:56,690 So, we're handling asynchronous behavior here 108 108 00:05:56,690 --> 00:05:59,831 with a callback just as we learned before, 109 109 00:05:59,831 --> 00:06:03,740 but anyway, let's go back to the code. 110 110 00:06:03,740 --> 00:06:07,284 And so, in the next line, we make an AJAX call using 111 111 00:06:07,284 --> 00:06:09,640 the fetch API. 112 112 00:06:09,640 --> 00:06:13,900 And as always the asynchronous fetch operation will happen 113 113 00:06:13,900 --> 00:06:16,470 in the web APIs environment. 114 114 00:06:16,470 --> 00:06:20,200 And again, that's because otherwise we would be blocking 115 115 00:06:20,200 --> 00:06:24,613 the call stack and create a huge lag in our application. 116 116 00:06:25,450 --> 00:06:29,160 Finally, we use the then method on the promise returned 117 117 00:06:29,160 --> 00:06:30,950 by the fetch function. 118 118 00:06:30,950 --> 00:06:33,520 And this will also register a callback 119 119 00:06:33,520 --> 00:06:37,410 in the web API environment so that we can react 120 120 00:06:37,410 --> 00:06:41,320 to the future resolved value of the promise. 121 121 00:06:41,320 --> 00:06:44,530 So this callback is associated with a promise 122 122 00:06:44,530 --> 00:06:47,350 that is fetching the data from the API. 123 123 00:06:47,350 --> 00:06:49,493 And that's gonna be important later on. 124 124 00:06:50,770 --> 00:06:53,920 So, with this, we have now executed all the 125 125 00:06:53,920 --> 00:06:55,500 top level of code. 126 126 00:06:55,500 --> 00:06:59,250 So, all the code that is not inside any callback function 127 127 00:06:59,250 --> 00:07:01,760 in asynchronous way. 128 128 00:07:01,760 --> 00:07:04,760 We also have the image loading in the background 129 129 00:07:04,760 --> 00:07:08,070 and some data being fetched from an API. 130 130 00:07:08,070 --> 00:07:11,965 And so now it's time for this to get really interesting. 131 131 00:07:11,965 --> 00:07:15,320 Let's say the image has finished loading 132 132 00:07:15,320 --> 00:07:19,890 and therefore the load event is emitted on that image. 133 133 00:07:19,890 --> 00:07:21,200 What happens next, 134 134 00:07:21,200 --> 00:07:24,310 is that the callback for this event is put 135 135 00:07:24,310 --> 00:07:25,513 into callback queue. 136 136 00:07:26,410 --> 00:07:29,870 And the callback queue is basically an ordered list 137 137 00:07:29,870 --> 00:07:32,010 of all the callback functions that are 138 138 00:07:32,010 --> 00:07:34,540 in line to be executed. 139 139 00:07:34,540 --> 00:07:37,360 And you can think of this callback queue, 140 140 00:07:37,360 --> 00:07:39,350 as a to do list that you would write 141 141 00:07:39,350 --> 00:07:43,540 for yourself with all the tasks that you have to complete. 142 142 00:07:43,540 --> 00:07:47,615 So, the callback queue is also a to do list of a kind, 143 143 00:07:47,615 --> 00:07:51,260 but with tasks that the call stack will eventually 144 144 00:07:51,260 --> 00:07:52,951 have to complete. 145 145 00:07:52,951 --> 00:07:56,160 Now, in this example, there are no other callbacks 146 146 00:07:56,160 --> 00:07:59,670 in the queue yet, but there could be of course. 147 147 00:07:59,670 --> 00:08:02,540 So, if there were already other callbacks waiting 148 148 00:08:02,540 --> 00:08:06,630 in line, then this new callback would of course go straight 149 149 00:08:06,630 --> 00:08:08,670 to the end of the queue. 150 150 00:08:08,670 --> 00:08:11,570 And there it would sit patiently for its turn 151 151 00:08:11,570 --> 00:08:12,763 to finally run. 152 152 00:08:13,620 --> 00:08:16,703 And this actually has big implications. 153 153 00:08:16,703 --> 00:08:21,480 So, imagine that you set a timer for five seconds. 154 154 00:08:21,480 --> 00:08:25,650 And so after five seconds that timer's callback will be put 155 155 00:08:25,650 --> 00:08:28,420 on the callback queue, right. 156 156 00:08:28,420 --> 00:08:31,960 And let's say there were already other callbacks awaiting. 157 157 00:08:31,960 --> 00:08:34,970 And let's also say that it took one second 158 158 00:08:34,970 --> 00:08:37,690 to run all of those callbacks. 159 159 00:08:37,690 --> 00:08:41,580 Then, in that case, your timers callback would only run 160 160 00:08:41,580 --> 00:08:45,390 after six seconds and not after five. 161 161 00:08:45,390 --> 00:08:49,130 So, these six seconds are the five seconds that passed 162 162 00:08:49,130 --> 00:08:52,830 for the timer, plus the one second that it took 163 163 00:08:52,830 --> 00:08:56,070 to run all the other callbacks that were already waiting 164 164 00:08:56,070 --> 00:08:59,300 in line in front of your timer. 165 165 00:08:59,300 --> 00:09:02,540 So, what this means is that the timers duration 166 166 00:09:02,540 --> 00:09:05,980 that you define is not a guarantee. 167 167 00:09:05,980 --> 00:09:08,810 The only guarantee is that the timers callback 168 168 00:09:08,810 --> 00:09:11,610 will not run before five seconds, 169 169 00:09:11,610 --> 00:09:15,957 but it might very well run after five seconds have passed. 170 170 00:09:15,957 --> 00:09:19,970 So, it all depends on the state of the callback queue. 171 171 00:09:19,970 --> 00:09:22,870 And also another queue that we're gonna learn about 172 172 00:09:22,870 --> 00:09:24,470 in a second. 173 173 00:09:24,470 --> 00:09:27,890 Now, another thing that's important to mention here 174 174 00:09:27,890 --> 00:09:31,560 is that the callback queue also contains callbacks coming 175 175 00:09:31,560 --> 00:09:36,560 from DOM events like clicks or key presses or whatever. 176 176 00:09:36,900 --> 00:09:40,400 Now, we learned before that DOM events are not really 177 177 00:09:40,400 --> 00:09:43,390 asynchronous behavior, but they still use the 178 178 00:09:43,390 --> 00:09:46,870 callback queue to run their attached callbacks. 179 179 00:09:46,870 --> 00:09:51,360 So, if a click happens on a button with addEventListener 180 180 00:09:51,360 --> 00:09:55,240 then what will happen is just like what I illustrated here 181 181 00:09:55,240 --> 00:09:58,116 with the asynchronous load event. 182 182 00:09:58,116 --> 00:10:02,130 But anyway now it's time to finally learn about 183 183 00:10:02,130 --> 00:10:03,860 the event loop. 184 184 00:10:03,860 --> 00:10:06,870 So, here is what the event loop does. 185 185 00:10:06,870 --> 00:10:10,170 It looks into the call stack and determines whether 186 186 00:10:10,170 --> 00:10:11,730 it's empty or not. 187 187 00:10:11,730 --> 00:10:15,000 Except of course for the global context, 188 188 00:10:15,000 --> 00:10:17,819 then if the stack is indeed empty 189 189 00:10:17,819 --> 00:10:22,600 which means that there's currently no code being executed 190 190 00:10:22,600 --> 00:10:26,610 then it will take the first callback from the callback queue 191 191 00:10:26,610 --> 00:10:30,690 and put it on the call stack two will be executed. 192 192 00:10:30,690 --> 00:10:33,510 And this is called an event loop tick. 193 193 00:10:33,510 --> 00:10:36,330 So each time the event loop takes a callback 194 194 00:10:36,330 --> 00:10:37,960 from the callback queue. 195 195 00:10:37,960 --> 00:10:41,480 We say that there was an event loop tick. 196 196 00:10:41,480 --> 00:10:44,340 So, as we can see here the event loop 197 197 00:10:44,340 --> 00:10:46,650 has the extremely important task 198 198 00:10:46,650 --> 00:10:49,900 of doing coordination between the call stack 199 199 00:10:49,900 --> 00:10:52,630 and to callbacks in the callback queue. 200 200 00:10:52,630 --> 00:10:56,120 So, the event loop is basically who decides exactly 201 201 00:10:56,120 --> 00:10:58,675 when each callback is executed. 202 202 00:10:58,675 --> 00:11:03,050 We can also say that the event loop does the orchestration 203 203 00:11:03,050 --> 00:11:05,773 of this entire JavaScript runtime. 204 204 00:11:05,773 --> 00:11:09,943 Another thing that becomes clear from this whole explanation 205 205 00:11:09,943 --> 00:11:14,000 is that the JavaScript language itself has actually 206 206 00:11:14,000 --> 00:11:16,340 no sense of time. 207 207 00:11:16,340 --> 00:11:19,440 That's because everything that is asynchronous 208 208 00:11:19,440 --> 00:11:21,860 does not happen in the engine. 209 209 00:11:21,860 --> 00:11:25,740 It's the runtime who manages all the asynchronous behavior. 210 210 00:11:25,740 --> 00:11:27,970 And it's the event loop who decides 211 211 00:11:27,970 --> 00:11:30,810 which code will be executed next. 212 212 00:11:30,810 --> 00:11:33,400 But the engine itself simply executes 213 213 00:11:33,400 --> 00:11:35,333 whatever code it has given. 214 214 00:11:38,740 --> 00:11:42,517 Okay, so, this is of course, a lot to take in. 215 215 00:11:42,517 --> 00:11:46,246 So let's try to recap what's happened here. 216 216 00:11:46,246 --> 00:11:49,690 So, the image started loading asynchronously 217 217 00:11:49,690 --> 00:11:51,920 in the web APIs environment 218 218 00:11:51,920 --> 00:11:54,570 and not in the call stack, right. 219 219 00:11:54,570 --> 00:11:57,990 We then used addEventListener to attach 220 220 00:11:57,990 --> 00:12:01,330 a callback function to the image load event. 221 221 00:12:01,330 --> 00:12:05,390 And this callback is basically or asynchronous code 222 222 00:12:05,390 --> 00:12:08,640 it's code that we deferred into the future 223 223 00:12:08,640 --> 00:12:11,760 because we only want to execute it once the image 224 224 00:12:11,760 --> 00:12:13,520 has loaded. 225 225 00:12:13,520 --> 00:12:17,740 And in the meantime, the rest of the code kept running. 226 226 00:12:17,740 --> 00:12:21,710 Now addEventListener did not put the callback directly 227 227 00:12:21,710 --> 00:12:23,460 in the callback queue. 228 228 00:12:23,460 --> 00:12:27,270 It simply registered the callback, which then kept waiting 229 229 00:12:27,270 --> 00:12:30,790 in the web APIs environment until the load event 230 230 00:12:30,790 --> 00:12:32,570 was fired off. 231 231 00:12:32,570 --> 00:12:35,843 Only then the environment put the call back into queue. 232 232 00:12:36,800 --> 00:12:40,060 Then while in the queue the callback kept waiting 233 233 00:12:40,060 --> 00:12:42,190 for the event loop to pick it up 234 234 00:12:42,190 --> 00:12:44,690 and put it on the call stack. 235 235 00:12:44,690 --> 00:12:48,730 And this happened as soon as the callback was first in line 236 236 00:12:48,730 --> 00:12:51,260 and the call stack was empty. 237 237 00:12:51,260 --> 00:12:52,768 And, that's it actually. 238 238 00:12:52,768 --> 00:12:57,400 So, all this happened so that the image did not have to load 239 239 00:12:57,400 --> 00:13:00,110 in the call stack, but in the background 240 240 00:13:00,110 --> 00:13:01,693 in a non blocking way. 241 241 00:13:02,760 --> 00:13:06,270 So, in a nutshell, the web APIs environment, 242 242 00:13:06,270 --> 00:13:07,510 the callback queue 243 243 00:13:07,510 --> 00:13:11,200 and the event loop, all together, make it possible 244 244 00:13:11,200 --> 00:13:15,850 that asynchronous code can be executed in a non blocking way 245 245 00:13:15,850 --> 00:13:19,663 even with only one thread of execution in the engine. 246 246 00:13:20,810 --> 00:13:24,820 Wow, that was already a lot to understand, 247 247 00:13:24,820 --> 00:13:26,910 but we're not done yet. 248 248 00:13:26,910 --> 00:13:29,360 Because we still have to fetch function 249 249 00:13:29,360 --> 00:13:33,420 getting data from the AJAX call in the background. 250 250 00:13:33,420 --> 00:13:36,850 And this is basically happening with a promise. 251 251 00:13:36,850 --> 00:13:41,390 Remember, now with promises things work in a slightly 252 252 00:13:41,390 --> 00:13:45,290 different way which is why I included this promise example 253 253 00:13:45,290 --> 00:13:46,750 as well. 254 254 00:13:46,750 --> 00:13:50,350 So, let's say that the data has now finally arrived. 255 255 00:13:50,350 --> 00:13:53,130 And so the fetch is done. 256 256 00:13:53,130 --> 00:13:55,725 Now, callbacks related to promises 257 257 00:13:55,725 --> 00:13:58,530 like this one that we registered with the 258 258 00:13:58,530 --> 00:14:00,400 promises then method. 259 259 00:14:00,400 --> 00:14:04,100 Do actually not go into the callback queue. 260 260 00:14:04,100 --> 00:14:07,960 So, again this callback did we still have here, 261 261 00:14:07,960 --> 00:14:11,990 which is coming from a promise will not be moved into the 262 262 00:14:11,990 --> 00:14:13,450 callback queue. 263 263 00:14:13,450 --> 00:14:17,330 Instead, callbacks of promises have a special queue 264 264 00:14:17,330 --> 00:14:21,913 for themselves, which is the so called microtasks queue. 265 265 00:14:23,030 --> 00:14:26,990 Now, what is special about the microtasks queue is 266 266 00:14:26,990 --> 00:14:31,140 that it basically has priority over the callback queue. 267 267 00:14:31,140 --> 00:14:33,940 So, at the end of an event loop tick, 268 268 00:14:33,940 --> 00:14:36,270 so after a callback has been taken 269 269 00:14:36,270 --> 00:14:39,760 from the callback queue, the event loop will check 270 270 00:14:39,760 --> 00:14:43,750 if there are any callbacks in the microtasks queue. 271 271 00:14:43,750 --> 00:14:46,890 And if there are, it will run all of them 272 272 00:14:46,890 --> 00:14:49,410 before it will run any more callbacks 273 273 00:14:49,410 --> 00:14:51,353 from the regular callback queue. 274 274 00:14:52,270 --> 00:14:54,670 And, by the way, we call these callbacks 275 275 00:14:54,670 --> 00:14:57,300 from promises microtasks. 276 276 00:14:57,300 --> 00:15:00,700 And therefore the name microtasks queue. 277 277 00:15:00,700 --> 00:15:03,480 And there are actually other microtasks 278 278 00:15:03,480 --> 00:15:05,959 but that's not relevant here. 279 279 00:15:05,959 --> 00:15:08,930 So going back to our example, 280 280 00:15:08,930 --> 00:15:12,650 currently, we actually do have a microtask sitting 281 281 00:15:12,650 --> 00:15:17,063 in a microtasks queue, the call stack is also empty. 282 282 00:15:17,063 --> 00:15:21,170 And therefore the event loop will now take this callback 283 283 00:15:21,170 --> 00:15:24,470 and put it in the call stack just like it does with 284 284 00:15:24,470 --> 00:15:27,350 callbacks from the callback queue. 285 285 00:15:27,350 --> 00:15:31,560 And it doesn't matter if the callback queue is empty or not. 286 286 00:15:31,560 --> 00:15:34,573 So, this would have worked the exact same way 287 287 00:15:34,573 --> 00:15:38,580 even if there were some callbacks in the callback queue. 288 288 00:15:38,580 --> 00:15:43,196 And again, that's because microtasks always have priority. 289 289 00:15:43,196 --> 00:15:47,380 In practice, this means that microtasks can basically 290 290 00:15:47,380 --> 00:15:51,960 cut in line before all other regular callbacks. 291 291 00:15:51,960 --> 00:15:55,640 Now, if one microtask adds a new microtask 292 292 00:15:55,640 --> 00:15:59,050 then that new microtask is also executed 293 293 00:15:59,050 --> 00:16:02,210 before any callbacks from the callback queue. 294 294 00:16:02,210 --> 00:16:05,220 And this means that the microtasks queue 295 295 00:16:05,220 --> 00:16:08,240 can essentially starve the callback queue. 296 296 00:16:08,240 --> 00:16:11,710 Because if we keep adding more and more microtasks, 297 297 00:16:11,710 --> 00:16:16,220 then callbacks in the callback queue can never execute. 298 298 00:16:16,220 --> 00:16:18,730 Now, this is usually never a problem 299 299 00:16:18,730 --> 00:16:23,050 but I just wanted to mention this possibility here anyways, 300 300 00:16:23,050 --> 00:16:26,570 who knows maybe this will be an interview question 301 301 00:16:26,570 --> 00:16:28,100 for you someday. 302 302 00:16:28,100 --> 00:16:31,113 And if so, you'd now know the answer. 303 303 00:16:32,040 --> 00:16:35,720 But anyway, as you can hopefully see the idea 304 304 00:16:35,720 --> 00:16:39,190 of running asynchronous code with regular callbacks 305 305 00:16:39,190 --> 00:16:44,060 and with microtasks coming from promises is very similar. 306 306 00:16:44,060 --> 00:16:47,710 The only difference is that they go into different queues 307 307 00:16:47,710 --> 00:16:51,430 and that the event loop gives microtasks priority 308 308 00:16:51,430 --> 00:16:53,273 over regular callbacks. 309 309 00:16:54,520 --> 00:16:57,890 All right, and thats finally it. 310 310 00:16:57,890 --> 00:17:00,000 that's all you need to know about how 311 311 00:17:00,000 --> 00:17:04,010 asynchronous JavaScript really works behind the scenes. 312 312 00:17:04,010 --> 00:17:06,760 And I'm sure that this knowledge is gonna be 313 313 00:17:06,760 --> 00:17:09,820 extremely helpful and valuable to you. 314 314 00:17:09,820 --> 00:17:12,740 Because you're gonna be way more confident writing 315 315 00:17:12,740 --> 00:17:14,186 asynchronous code now. 316 316 00:17:14,186 --> 00:17:18,420 And also you will ace any job interview question 317 317 00:17:18,420 --> 00:17:21,490 about asynchronous JavaScript. 318 318 00:17:21,490 --> 00:17:25,190 And actually so many JavaScript developers don't know 319 319 00:17:25,190 --> 00:17:26,870 anything about this. 320 320 00:17:26,870 --> 00:17:29,720 So, I'm sure that this knowledge will put you 321 321 00:17:29,720 --> 00:17:34,720 into the top 10% or even top 5% of JavaScript developers. 322 322 00:17:36,300 --> 00:17:40,650 And that's just amazing on itself, right. 323 323 00:17:40,650 --> 00:17:43,020 But anyway, let's no finish here 324 324 00:17:43,020 --> 00:17:45,890 and try out some of this stuff in practice, 325 325 00:17:45,890 --> 00:17:48,070 so that you see for yourself 326 326 00:17:48,070 --> 00:17:50,273 that I didn't just make this stuff up. 29405