WEBVTT 1 00:00:01.240 --> 00:00:04.870 So, we learned what AJAX and APIs are. 2 00:00:04.870 --> 00:00:07.993 We used a bunch of asynchronous code already 3 00:00:07.993 --> 00:00:11.150 and we learned all about promises. 4 00:00:11.150 --> 00:00:14.810 But what's missing is to finally understand how all 5 00:00:14.810 --> 00:00:18.278 of it really works behind the scenes of JavaScript. 6 00:00:18.278 --> 00:00:20.093 And so let's find out. 7 00:00:23.109 --> 00:00:26.090 And to start let's quickly review the JavaScript runtime 8 00:00:26.090 --> 00:00:29.380 that we talked about way back in the course, 9 00:00:29.380 --> 00:00:32.680 just to make sure that the rest of this lecture will make 10 00:00:32.680 --> 00:00:33.513 sense to you. 11 00:00:34.450 --> 00:00:38.810 So, a JavaScript runtime is basically a container 12 00:00:38.810 --> 00:00:41.200 which includes all the different pieces 13 00:00:41.200 --> 00:00:44.838 that are necessary to execute JavaScript code. 14 00:00:44.838 --> 00:00:49.838 Now, the heart of every JavaScript runtime is the engine. 15 00:00:50.230 --> 00:00:53.690 So, this is where code is actually executed 16 00:00:53.690 --> 00:00:57.070 and where objects are stored in memory. 17 00:00:57.070 --> 00:00:59.960 So, these two things happen in the call stack 18 00:00:59.960 --> 00:01:00.973 and in the heap. 19 00:01:01.820 --> 00:01:04.170 Now, what's important to note here is 20 00:01:04.170 --> 00:01:08.200 that JavaScript has only one threat of execution. 21 00:01:08.200 --> 00:01:11.560 And so it can only do one thing at a time. 22 00:01:11.560 --> 00:01:14.810 There is absolutely no multitasking happening 23 00:01:14.810 --> 00:01:17.170 in JavaScript itself. 24 00:01:17.170 --> 00:01:20.960 Now, other languages like Java can execute multiple pieces 25 00:01:20.960 --> 00:01:24.963 of code at the same time, but not JavaScript. 26 00:01:24.963 --> 00:01:29.963 But anyway, next we have the web APIs environment. 27 00:01:30.610 --> 00:01:34.050 These are some APIs provided to the engine, 28 00:01:34.050 --> 00:01:36.567 but which are actually not part of 29 00:01:36.567 --> 00:01:38.773 the JavaScript language itself. 30 00:01:40.510 --> 00:01:42.800 So, that's things like the DOM timers 31 00:01:42.800 --> 00:01:47.800 the fetch API, the geolocation API, and so on and so forth. 32 00:01:48.740 --> 00:01:51.630 Next up, there is the callback queue 33 00:01:51.630 --> 00:01:54.900 and this is a data structure that holds all the ready 34 00:01:54.900 --> 00:01:58.480 to be executed callback functions that are attached 35 00:01:58.480 --> 00:02:00.793 to some event that has occurred. 36 00:02:01.650 --> 00:02:04.800 Finally, whenever the call stack is empty 37 00:02:04.800 --> 00:02:08.220 the event loop takes callbacks from the callback queue 38 00:02:08.220 --> 00:02:12.710 and puts them into call stack so that they can be executed. 39 00:02:12.710 --> 00:02:14.900 So the event loop is the essential 40 00:02:14.900 --> 00:02:18.070 piece that makes asynchronous behavior possible 41 00:02:18.070 --> 00:02:19.660 in JavaScript. 42 00:02:19.660 --> 00:02:21.640 It's the reason why we can have a 43 00:02:21.640 --> 00:02:25.170 non blocking concurrency model in JavaScript. 44 00:02:25.170 --> 00:02:29.320 And a concurrency model is simply how a language handles 45 00:02:29.320 --> 00:02:32.840 multiple things happening at the same time. 46 00:02:32.840 --> 00:02:34.510 But now how does this 47 00:02:34.510 --> 00:02:37.860 non blocking concurrency actually work? 48 00:02:37.860 --> 00:02:41.370 And why is the event loop so important? 49 00:02:41.370 --> 00:02:43.053 Well, let's find out. 50 00:02:44.950 --> 00:02:49.460 And let's focus on the essential parts of the runtime here. 51 00:02:49.460 --> 00:02:53.650 So, that's the call stack the event loop the web APIs 52 00:02:53.650 --> 00:02:55.620 and to callback queue. 53 00:02:55.620 --> 00:02:59.650 So, as you know, by now, a JavaScript engine is built 54 00:02:59.650 --> 00:03:02.720 around the idea of a single threat. 55 00:03:02.720 --> 00:03:06.860 But if there was only one thread of execution in the engine 56 00:03:06.860 --> 00:03:09.890 then how can asynchronous code be executed 57 00:03:09.890 --> 00:03:11.960 in a non blocking way? 58 00:03:11.960 --> 00:03:14.490 Well, that's actually the big question 59 00:03:14.490 --> 00:03:16.483 that we're gonna answer in this video. 60 00:03:17.370 --> 00:03:19.240 So, essentially you will learn 61 00:03:19.240 --> 00:03:22.450 how the JavaScript concurrency model really works 62 00:03:22.450 --> 00:03:25.480 behind the scenes, using all the parts of the 63 00:03:25.480 --> 00:03:28.630 JavaScript runtime that you already know. 64 00:03:28.630 --> 00:03:31.170 And as always, we will do this by looking 65 00:03:31.170 --> 00:03:33.780 at a real code example. 66 00:03:33.780 --> 00:03:35.730 So, let's walk through the code line 67 00:03:35.730 --> 00:03:40.009 by line and I will keep updating the call stack as we go, 68 00:03:40.009 --> 00:03:43.720 however, you already know how to call stack works. 69 00:03:43.720 --> 00:03:46.030 And so it's best that you focus more 70 00:03:46.030 --> 00:03:50.258 on the code and on the web APIs and callback queue. 71 00:03:50.258 --> 00:03:55.150 Okay, but now let's start by selecting this image element. 72 00:03:55.150 --> 00:03:56.800 And then in the next line 73 00:03:56.800 --> 00:04:01.643 we set the source attribute of that image to dog.jpg. 74 00:04:02.540 --> 00:04:06.250 And as we learned before this will now start to load 75 00:04:06.250 --> 00:04:10.040 this image asynchronously in the background. 76 00:04:10.040 --> 00:04:12.520 But this time we can actually understand 77 00:04:12.520 --> 00:04:15.955 what that mysterious background actually is. 78 00:04:15.955 --> 00:04:20.084 So, as you already know everything related to the DOM 79 00:04:20.084 --> 00:04:25.084 is not really part of JavaScript, but of the web APIs. 80 00:04:25.890 --> 00:04:29.100 And so it's in a web APIs environment where 81 00:04:29.100 --> 00:04:33.600 the asynchronous tasks related to the DOM will run. 82 00:04:33.600 --> 00:04:38.200 And in fact, the same is true for timers AJAX calls 83 00:04:38.200 --> 00:04:41.630 and really all other asynchronous tasks. 84 00:04:41.630 --> 00:04:45.440 So, again, these asynchronous tasks will all run 85 00:04:45.440 --> 00:04:48.443 in the web API environment of the browser. 86 00:04:49.360 --> 00:04:53.170 Now, if the image would be loading in a synchronous way 87 00:04:53.170 --> 00:04:56.280 it would be doing so right in the call stack 88 00:04:56.280 --> 00:05:00.090 blocking the execution of the rest of the code. 89 00:05:00.090 --> 00:05:03.970 But, as we already learned, that would be terrible. 90 00:05:03.970 --> 00:05:08.640 And that's why loading images in JavaScript is asynchronous. 91 00:05:08.640 --> 00:05:11.560 So it does not happen in the call stack. 92 00:05:11.560 --> 00:05:14.900 So, not in the main thread of execution, 93 00:05:14.900 --> 00:05:17.600 but really in the web APIs environment 94 00:05:17.600 --> 00:05:18.903 as I mentioned before. 95 00:05:19.780 --> 00:05:22.700 Now, if we want to do something after the image 96 00:05:22.700 --> 00:05:24.230 has finished loading, 97 00:05:24.230 --> 00:05:27.150 then we need to listen to the load event. 98 00:05:27.150 --> 00:05:31.600 And so that's exactly what we do in the next line of code. 99 00:05:31.600 --> 00:05:33.780 So, here we attach an event listener 100 00:05:33.780 --> 00:05:36.520 to the load event of that image 101 00:05:36.520 --> 00:05:39.193 and pass an a callback function as always. 102 00:05:40.060 --> 00:05:43.610 In practice, this means to register this callback 103 00:05:43.610 --> 00:05:46.060 in the web APIs environment, 104 00:05:46.060 --> 00:05:48.970 exactly where the image is loading. 105 00:05:48.970 --> 00:05:51.000 And to callback will stay there 106 00:05:51.000 --> 00:05:53.456 until the load event is emitted. 107 00:05:53.456 --> 00:05:56.690 So, we're handling asynchronous behavior here 108 00:05:56.690 --> 00:05:59.831 with a callback just as we learned before, 109 00:05:59.831 --> 00:06:03.740 but anyway, let's go back to the code. 110 00:06:03.740 --> 00:06:07.284 And so, in the next line, we make an AJAX call using 111 00:06:07.284 --> 00:06:09.640 the fetch API. 112 00:06:09.640 --> 00:06:13.900 And as always the asynchronous fetch operation will happen 113 00:06:13.900 --> 00:06:16.470 in the web APIs environment. 114 00:06:16.470 --> 00:06:20.200 And again, that's because otherwise we would be blocking 115 00:06:20.200 --> 00:06:24.613 the call stack and create a huge lag in our application. 116 00:06:25.450 --> 00:06:29.160 Finally, we use the then method on the promise returned 117 00:06:29.160 --> 00:06:30.950 by the fetch function. 118 00:06:30.950 --> 00:06:33.520 And this will also register a callback 119 00:06:33.520 --> 00:06:37.410 in the web API environment so that we can react 120 00:06:37.410 --> 00:06:41.320 to the future resolved value of the promise. 121 00:06:41.320 --> 00:06:44.530 So this callback is associated with a promise 122 00:06:44.530 --> 00:06:47.350 that is fetching the data from the API. 123 00:06:47.350 --> 00:06:49.493 And that's gonna be important later on. 124 00:06:50.770 --> 00:06:53.920 So, with this, we have now executed all the 125 00:06:53.920 --> 00:06:55.500 top level of code. 126 00:06:55.500 --> 00:06:59.250 So, all the code that is not inside any callback function 127 00:06:59.250 --> 00:07:01.760 in asynchronous way. 128 00:07:01.760 --> 00:07:04.760 We also have the image loading in the background 129 00:07:04.760 --> 00:07:08.070 and some data being fetched from an API. 130 00:07:08.070 --> 00:07:11.965 And so now it's time for this to get really interesting. 131 00:07:11.965 --> 00:07:15.320 Let's say the image has finished loading 132 00:07:15.320 --> 00:07:19.890 and therefore the load event is emitted on that image. 133 00:07:19.890 --> 00:07:21.200 What happens next, 134 00:07:21.200 --> 00:07:24.310 is that the callback for this event is put 135 00:07:24.310 --> 00:07:25.513 into callback queue. 136 00:07:26.410 --> 00:07:29.870 And the callback queue is basically an ordered list 137 00:07:29.870 --> 00:07:32.010 of all the callback functions that are 138 00:07:32.010 --> 00:07:34.540 in line to be executed. 139 00:07:34.540 --> 00:07:37.360 And you can think of this callback queue, 140 00:07:37.360 --> 00:07:39.350 as a to do list that you would write 141 00:07:39.350 --> 00:07:43.540 for yourself with all the tasks that you have to complete. 142 00:07:43.540 --> 00:07:47.615 So, the callback queue is also a to do list of a kind, 143 00:07:47.615 --> 00:07:51.260 but with tasks that the call stack will eventually 144 00:07:51.260 --> 00:07:52.951 have to complete. 145 00:07:52.951 --> 00:07:56.160 Now, in this example, there are no other callbacks 146 00:07:56.160 --> 00:07:59.670 in the queue yet, but there could be of course. 147 00:07:59.670 --> 00:08:02.540 So, if there were already other callbacks waiting 148 00:08:02.540 --> 00:08:06.630 in line, then this new callback would of course go straight 149 00:08:06.630 --> 00:08:08.670 to the end of the queue. 150 00:08:08.670 --> 00:08:11.570 And there it would sit patiently for its turn 151 00:08:11.570 --> 00:08:12.763 to finally run. 152 00:08:13.620 --> 00:08:16.703 And this actually has big implications. 153 00:08:16.703 --> 00:08:21.480 So, imagine that you set a timer for five seconds. 154 00:08:21.480 --> 00:08:25.650 And so after five seconds that timer's callback will be put 155 00:08:25.650 --> 00:08:28.420 on the callback queue, right. 156 00:08:28.420 --> 00:08:31.960 And let's say there were already other callbacks awaiting. 157 00:08:31.960 --> 00:08:34.970 And let's also say that it took one second 158 00:08:34.970 --> 00:08:37.690 to run all of those callbacks. 159 00:08:37.690 --> 00:08:41.580 Then, in that case, your timers callback would only run 160 00:08:41.580 --> 00:08:45.390 after six seconds and not after five. 161 00:08:45.390 --> 00:08:49.130 So, these six seconds are the five seconds that passed 162 00:08:49.130 --> 00:08:52.830 for the timer, plus the one second that it took 163 00:08:52.830 --> 00:08:56.070 to run all the other callbacks that were already waiting 164 00:08:56.070 --> 00:08:59.300 in line in front of your timer. 165 00:08:59.300 --> 00:09:02.540 So, what this means is that the timers duration 166 00:09:02.540 --> 00:09:05.980 that you define is not a guarantee. 167 00:09:05.980 --> 00:09:08.810 The only guarantee is that the timers callback 168 00:09:08.810 --> 00:09:11.610 will not run before five seconds, 169 00:09:11.610 --> 00:09:15.957 but it might very well run after five seconds have passed. 170 00:09:15.957 --> 00:09:19.970 So, it all depends on the state of the callback queue. 171 00:09:19.970 --> 00:09:22.870 And also another queue that we're gonna learn about 172 00:09:22.870 --> 00:09:24.470 in a second. 173 00:09:24.470 --> 00:09:27.890 Now, another thing that's important to mention here 174 00:09:27.890 --> 00:09:31.560 is that the callback queue also contains callbacks coming 175 00:09:31.560 --> 00:09:36.560 from DOM events like clicks or key presses or whatever. 176 00:09:36.900 --> 00:09:40.400 Now, we learned before that DOM events are not really 177 00:09:40.400 --> 00:09:43.390 asynchronous behavior, but they still use the 178 00:09:43.390 --> 00:09:46.870 callback queue to run their attached callbacks. 179 00:09:46.870 --> 00:09:51.360 So, if a click happens on a button with addEventListener 180 00:09:51.360 --> 00:09:55.240 then what will happen is just like what I illustrated here 181 00:09:55.240 --> 00:09:58.116 with the asynchronous load event. 182 00:09:58.116 --> 00:10:02.130 But anyway now it's time to finally learn about 183 00:10:02.130 --> 00:10:03.860 the event loop. 184 00:10:03.860 --> 00:10:06.870 So, here is what the event loop does. 185 00:10:06.870 --> 00:10:10.170 It looks into the call stack and determines whether 186 00:10:10.170 --> 00:10:11.730 it's empty or not. 187 00:10:11.730 --> 00:10:15.000 Except of course for the global context, 188 00:10:15.000 --> 00:10:17.819 then if the stack is indeed empty 189 00:10:17.819 --> 00:10:22.600 which means that there's currently no code being executed 190 00:10:22.600 --> 00:10:26.610 then it will take the first callback from the callback queue 191 00:10:26.610 --> 00:10:30.690 and put it on the call stack two will be executed. 192 00:10:30.690 --> 00:10:33.510 And this is called an event loop tick. 193 00:10:33.510 --> 00:10:36.330 So each time the event loop takes a callback 194 00:10:36.330 --> 00:10:37.960 from the callback queue. 195 00:10:37.960 --> 00:10:41.480 We say that there was an event loop tick. 196 00:10:41.480 --> 00:10:44.340 So, as we can see here the event loop 197 00:10:44.340 --> 00:10:46.650 has the extremely important task 198 00:10:46.650 --> 00:10:49.900 of doing coordination between the call stack 199 00:10:49.900 --> 00:10:52.630 and to callbacks in the callback queue. 200 00:10:52.630 --> 00:10:56.120 So, the event loop is basically who decides exactly 201 00:10:56.120 --> 00:10:58.675 when each callback is executed. 202 00:10:58.675 --> 00:11:03.050 We can also say that the event loop does the orchestration 203 00:11:03.050 --> 00:11:05.773 of this entire JavaScript runtime. 204 00:11:05.773 --> 00:11:09.943 Another thing that becomes clear from this whole explanation 205 00:11:09.943 --> 00:11:14.000 is that the JavaScript language itself has actually 206 00:11:14.000 --> 00:11:16.340 no sense of time. 207 00:11:16.340 --> 00:11:19.440 That's because everything that is asynchronous 208 00:11:19.440 --> 00:11:21.860 does not happen in the engine. 209 00:11:21.860 --> 00:11:25.740 It's the runtime who manages all the asynchronous behavior. 210 00:11:25.740 --> 00:11:27.970 And it's the event loop who decides 211 00:11:27.970 --> 00:11:30.810 which code will be executed next. 212 00:11:30.810 --> 00:11:33.400 But the engine itself simply executes 213 00:11:33.400 --> 00:11:35.333 whatever code it has given. 214 00:11:38.740 --> 00:11:42.517 Okay, so, this is of course, a lot to take in. 215 00:11:42.517 --> 00:11:46.246 So let's try to recap what's happened here. 216 00:11:46.246 --> 00:11:49.690 So, the image started loading asynchronously 217 00:11:49.690 --> 00:11:51.920 in the web APIs environment 218 00:11:51.920 --> 00:11:54.570 and not in the call stack, right. 219 00:11:54.570 --> 00:11:57.990 We then used addEventListener to attach 220 00:11:57.990 --> 00:12:01.330 a callback function to the image load event. 221 00:12:01.330 --> 00:12:05.390 And this callback is basically or asynchronous code 222 00:12:05.390 --> 00:12:08.640 it's code that we deferred into the future 223 00:12:08.640 --> 00:12:11.760 because we only want to execute it once the image 224 00:12:11.760 --> 00:12:13.520 has loaded. 225 00:12:13.520 --> 00:12:17.740 And in the meantime, the rest of the code kept running. 226 00:12:17.740 --> 00:12:21.710 Now addEventListener did not put the callback directly 227 00:12:21.710 --> 00:12:23.460 in the callback queue. 228 00:12:23.460 --> 00:12:27.270 It simply registered the callback, which then kept waiting 229 00:12:27.270 --> 00:12:30.790 in the web APIs environment until the load event 230 00:12:30.790 --> 00:12:32.570 was fired off. 231 00:12:32.570 --> 00:12:35.843 Only then the environment put the call back into queue. 232 00:12:36.800 --> 00:12:40.060 Then while in the queue the callback kept waiting 233 00:12:40.060 --> 00:12:42.190 for the event loop to pick it up 234 00:12:42.190 --> 00:12:44.690 and put it on the call stack. 235 00:12:44.690 --> 00:12:48.730 And this happened as soon as the callback was first in line 236 00:12:48.730 --> 00:12:51.260 and the call stack was empty. 237 00:12:51.260 --> 00:12:52.768 And, that's it actually. 238 00:12:52.768 --> 00:12:57.400 So, all this happened so that the image did not have to load 239 00:12:57.400 --> 00:13:00.110 in the call stack, but in the background 240 00:13:00.110 --> 00:13:01.693 in a non blocking way. 241 00:13:02.760 --> 00:13:06.270 So, in a nutshell, the web APIs environment, 242 00:13:06.270 --> 00:13:07.510 the callback queue 243 00:13:07.510 --> 00:13:11.200 and the event loop, all together, make it possible 244 00:13:11.200 --> 00:13:15.850 that asynchronous code can be executed in a non blocking way 245 00:13:15.850 --> 00:13:19.663 even with only one thread of execution in the engine. 246 00:13:20.810 --> 00:13:24.820 Wow, that was already a lot to understand, 247 00:13:24.820 --> 00:13:26.910 but we're not done yet. 248 00:13:26.910 --> 00:13:29.360 Because we still have to fetch function 249 00:13:29.360 --> 00:13:33.420 getting data from the AJAX call in the background. 250 00:13:33.420 --> 00:13:36.850 And this is basically happening with a promise. 251 00:13:36.850 --> 00:13:41.390 Remember, now with promises things work in a slightly 252 00:13:41.390 --> 00:13:45.290 different way which is why I included this promise example 253 00:13:45.290 --> 00:13:46.750 as well. 254 00:13:46.750 --> 00:13:50.350 So, let's say that the data has now finally arrived. 255 00:13:50.350 --> 00:13:53.130 And so the fetch is done. 256 00:13:53.130 --> 00:13:55.725 Now, callbacks related to promises 257 00:13:55.725 --> 00:13:58.530 like this one that we registered with the 258 00:13:58.530 --> 00:14:00.400 promises then method. 259 00:14:00.400 --> 00:14:04.100 Do actually not go into the callback queue. 260 00:14:04.100 --> 00:14:07.960 So, again this callback did we still have here, 261 00:14:07.960 --> 00:14:11.990 which is coming from a promise will not be moved into the 262 00:14:11.990 --> 00:14:13.450 callback queue. 263 00:14:13.450 --> 00:14:17.330 Instead, callbacks of promises have a special queue 264 00:14:17.330 --> 00:14:21.913 for themselves, which is the so called microtasks queue. 265 00:14:23.030 --> 00:14:26.990 Now, what is special about the microtasks queue is 266 00:14:26.990 --> 00:14:31.140 that it basically has priority over the callback queue. 267 00:14:31.140 --> 00:14:33.940 So, at the end of an event loop tick, 268 00:14:33.940 --> 00:14:36.270 so after a callback has been taken 269 00:14:36.270 --> 00:14:39.760 from the callback queue, the event loop will check 270 00:14:39.760 --> 00:14:43.750 if there are any callbacks in the microtasks queue. 271 00:14:43.750 --> 00:14:46.890 And if there are, it will run all of them 272 00:14:46.890 --> 00:14:49.410 before it will run any more callbacks 273 00:14:49.410 --> 00:14:51.353 from the regular callback queue. 274 00:14:52.270 --> 00:14:54.670 And, by the way, we call these callbacks 275 00:14:54.670 --> 00:14:57.300 from promises microtasks. 276 00:14:57.300 --> 00:15:00.700 And therefore the name microtasks queue. 277 00:15:00.700 --> 00:15:03.480 And there are actually other microtasks 278 00:15:03.480 --> 00:15:05.959 but that's not relevant here. 279 00:15:05.959 --> 00:15:08.930 So going back to our example, 280 00:15:08.930 --> 00:15:12.650 currently, we actually do have a microtask sitting 281 00:15:12.650 --> 00:15:17.063 in a microtasks queue, the call stack is also empty. 282 00:15:17.063 --> 00:15:21.170 And therefore the event loop will now take this callback 283 00:15:21.170 --> 00:15:24.470 and put it in the call stack just like it does with 284 00:15:24.470 --> 00:15:27.350 callbacks from the callback queue. 285 00:15:27.350 --> 00:15:31.560 And it doesn't matter if the callback queue is empty or not. 286 00:15:31.560 --> 00:15:34.573 So, this would have worked the exact same way 287 00:15:34.573 --> 00:15:38.580 even if there were some callbacks in the callback queue. 288 00:15:38.580 --> 00:15:43.196 And again, that's because microtasks always have priority. 289 00:15:43.196 --> 00:15:47.380 In practice, this means that microtasks can basically 290 00:15:47.380 --> 00:15:51.960 cut in line before all other regular callbacks. 291 00:15:51.960 --> 00:15:55.640 Now, if one microtask adds a new microtask 292 00:15:55.640 --> 00:15:59.050 then that new microtask is also executed 293 00:15:59.050 --> 00:16:02.210 before any callbacks from the callback queue. 294 00:16:02.210 --> 00:16:05.220 And this means that the microtasks queue 295 00:16:05.220 --> 00:16:08.240 can essentially starve the callback queue. 296 00:16:08.240 --> 00:16:11.710 Because if we keep adding more and more microtasks, 297 00:16:11.710 --> 00:16:16.220 then callbacks in the callback queue can never execute. 298 00:16:16.220 --> 00:16:18.730 Now, this is usually never a problem 299 00:16:18.730 --> 00:16:23.050 but I just wanted to mention this possibility here anyways, 300 00:16:23.050 --> 00:16:26.570 who knows maybe this will be an interview question 301 00:16:26.570 --> 00:16:28.100 for you someday. 302 00:16:28.100 --> 00:16:31.113 And if so, you'd now know the answer. 303 00:16:32.040 --> 00:16:35.720 But anyway, as you can hopefully see the idea 304 00:16:35.720 --> 00:16:39.190 of running asynchronous code with regular callbacks 305 00:16:39.190 --> 00:16:44.060 and with microtasks coming from promises is very similar. 306 00:16:44.060 --> 00:16:47.710 The only difference is that they go into different queues 307 00:16:47.710 --> 00:16:51.430 and that the event loop gives microtasks priority 308 00:16:51.430 --> 00:16:53.273 over regular callbacks. 309 00:16:54.520 --> 00:16:57.890 All right, and thats finally it. 310 00:16:57.890 --> 00:17:00.000 that's all you need to know about how 311 00:17:00.000 --> 00:17:04.010 asynchronous JavaScript really works behind the scenes. 312 00:17:04.010 --> 00:17:06.760 And I'm sure that this knowledge is gonna be 313 00:17:06.760 --> 00:17:09.820 extremely helpful and valuable to you. 314 00:17:09.820 --> 00:17:12.740 Because you're gonna be way more confident writing 315 00:17:12.740 --> 00:17:14.186 asynchronous code now. 316 00:17:14.186 --> 00:17:18.420 And also you will ace any job interview question 317 00:17:18.420 --> 00:17:21.490 about asynchronous JavaScript. 318 00:17:21.490 --> 00:17:25.190 And actually so many JavaScript developers don't know 319 00:17:25.190 --> 00:17:26.870 anything about this. 320 00:17:26.870 --> 00:17:29.720 So, I'm sure that this knowledge will put you 321 00:17:29.720 --> 00:17:34.720 into the top 10% or even top 5% of JavaScript developers. 322 00:17:36.300 --> 00:17:40.650 And that's just amazing on itself, right. 323 00:17:40.650 --> 00:17:43.020 But anyway, let's no finish here 324 00:17:43.020 --> 00:17:45.890 and try out some of this stuff in practice, 325 00:17:45.890 --> 00:17:48.070 so that you see for yourself 326 00:17:48.070 --> 00:17:50.273 that I didn't just make this stuff up.