WEBVTT 1 00:00:00.930 --> 00:00:04.100 In this lecture, let's answer the question. 2 00:00:04.100 --> 00:00:07.080 How is JavaScript code executed? 3 00:00:07.080 --> 00:00:09.890 We already know that it happens in a call stack 4 00:00:09.890 --> 00:00:13.373 in the engine, but let's dig a bit deeper now. 5 00:00:14.790 --> 00:00:15.750 And let's start 6 00:00:15.750 --> 00:00:20.020 by supposing that our code was just finished compiling. 7 00:00:20.020 --> 00:00:23.240 Just in the way that we learned in the last lecture. 8 00:00:23.240 --> 00:00:26.860 So the code is now ready to be executed. 9 00:00:26.860 --> 00:00:28.160 What happens then, 10 00:00:28.160 --> 00:00:32.890 is that a so-called global execution context is created 11 00:00:32.890 --> 00:00:35.280 for the top-level code. 12 00:00:35.280 --> 00:00:38.860 And top-level code is basically code that is not 13 00:00:38.860 --> 00:00:41.000 inside any function. 14 00:00:41.000 --> 00:00:43.330 So again, in the beginning 15 00:00:43.330 --> 00:00:48.330 only the code that is outside of functions will be executed. 16 00:00:48.410 --> 00:00:50.530 And this makes sense, right? 17 00:00:50.530 --> 00:00:54.370 Functions should only be executed when they are called. 18 00:00:54.370 --> 00:00:57.020 And actually we saw this happening already 19 00:00:57.020 --> 00:00:59.230 in our pig game project. 20 00:00:59.230 --> 00:01:01.490 So there we had an init function, 21 00:01:01.490 --> 00:01:04.400 which initialized our entire project 22 00:01:04.400 --> 00:01:07.210 but in order to actually initialize the game 23 00:01:07.210 --> 00:01:09.480 the first time that the page loaded, 24 00:01:09.480 --> 00:01:12.200 we needed to call that function immediately 25 00:01:12.200 --> 00:01:14.160 in our top-level code. 26 00:01:14.160 --> 00:01:16.500 And so that's what I mean here. 27 00:01:16.500 --> 00:01:18.490 But anyway, we can also see 28 00:01:18.490 --> 00:01:22.560 what top-level code is in this example here. 29 00:01:22.560 --> 00:01:24.860 So this name variable declaration 30 00:01:24.860 --> 00:01:27.950 is clearly top-level code right? 31 00:01:27.950 --> 00:01:30.330 And therefore it will be executed 32 00:01:30.330 --> 00:01:33.200 in the global execution context. 33 00:01:33.200 --> 00:01:36.860 Next, we have two functions, one expression, 34 00:01:36.860 --> 00:01:38.800 and one declaration. 35 00:01:38.800 --> 00:01:41.000 So these will also be declared, 36 00:01:41.000 --> 00:01:43.230 so that they can be called later. 37 00:01:43.230 --> 00:01:45.430 But the code inside the functions, 38 00:01:45.430 --> 00:01:49.890 will only be executed when the functions are called. 39 00:01:49.890 --> 00:01:53.880 Okay, so we know that a global execution context 40 00:01:53.880 --> 00:01:56.910 is created for top-level code. 41 00:01:56.910 --> 00:02:01.260 But now what exactly is an execution context? 42 00:02:01.260 --> 00:02:05.410 Well, an execution context is an abstract concept. 43 00:02:05.410 --> 00:02:08.400 But I define it basically as an environment 44 00:02:08.400 --> 00:02:12.510 in which a piece of JavaScript is executed. 45 00:02:12.510 --> 00:02:16.700 It's like a box that stores all the necessary information 46 00:02:16.700 --> 00:02:19.290 for some code to be executed. 47 00:02:19.290 --> 00:02:24.290 Such as local variables or arguments passed into a function. 48 00:02:24.590 --> 00:02:29.590 So, JavaScript code always runs inside an execution context. 49 00:02:29.930 --> 00:02:32.340 And to make this a bit more intuitive 50 00:02:32.340 --> 00:02:36.720 let's imagine you order a pizza at a takeaway. 51 00:02:36.720 --> 00:02:41.050 So usually that pizza comes in a box right? 52 00:02:41.050 --> 00:02:42.700 And it might also come 53 00:02:42.700 --> 00:02:45.440 with some other stuff that is necessary 54 00:02:45.440 --> 00:02:49.900 for you to eat a pizza such as cutlery or a receipt, 55 00:02:49.900 --> 00:02:54.150 so that you can actually pay for the pizza before eating it. 56 00:02:54.150 --> 00:02:55.730 So, in this analogy, 57 00:02:55.730 --> 00:02:59.640 the pizza is the JavaScript code to be executed, 58 00:02:59.640 --> 00:03:03.070 and the box is of course the execution context 59 00:03:03.070 --> 00:03:04.600 for our pizza. 60 00:03:04.600 --> 00:03:08.820 And that's because eating the pizza happens inside the box 61 00:03:08.820 --> 00:03:12.830 which is then the environment for eating pizza. 62 00:03:12.830 --> 00:03:16.440 The box also contains cutlery and the receipt, 63 00:03:16.440 --> 00:03:19.170 which are necessary to eat a pizza 64 00:03:19.170 --> 00:03:23.970 or in other words, to execute the code, okay? 65 00:03:23.970 --> 00:03:25.540 I hope that made sense, 66 00:03:25.540 --> 00:03:28.380 and to made the concept of execution context 67 00:03:28.380 --> 00:03:30.700 a little bit more clear. 68 00:03:30.700 --> 00:03:35.150 Now, in any JavaScript project, no matter how large it is, 69 00:03:35.150 --> 00:03:39.030 there is only ever one global execution context. 70 00:03:39.030 --> 00:03:41.830 It's always there as the default context, 71 00:03:41.830 --> 00:03:45.250 and it's where top-level code will execute. 72 00:03:45.250 --> 00:03:47.160 And speaking of execute, 73 00:03:47.160 --> 00:03:49.270 now that we have an environment 74 00:03:49.270 --> 00:03:52.300 where the top-level code can be executed, 75 00:03:52.300 --> 00:03:54.600 it finally is executed. 76 00:03:54.600 --> 00:03:59.420 And there is not a lot to say about the execution itself. 77 00:03:59.420 --> 00:04:02.500 It's just the computer CPU processing 78 00:04:02.500 --> 00:04:05.690 the machine code that it received. 79 00:04:05.690 --> 00:04:08.290 Okay, and once this first code, 80 00:04:08.290 --> 00:04:11.100 so the top-level of code is finished, 81 00:04:11.100 --> 00:04:14.950 functions finally start to execute as well. 82 00:04:14.950 --> 00:04:16.850 And here is how that works. 83 00:04:16.850 --> 00:04:18.813 For each and every function call, 84 00:04:18.813 --> 00:04:22.120 and you execution context will be created 85 00:04:22.120 --> 00:04:25.280 containing all the information that is necessary 86 00:04:25.280 --> 00:04:28.070 to run exactly that function. 87 00:04:28.070 --> 00:04:30.880 And the same goes for methods, of course, 88 00:04:30.880 --> 00:04:32.750 because they're simply functions 89 00:04:32.750 --> 00:04:36.180 attached to objects remember? 90 00:04:36.180 --> 00:04:39.590 Anyway, all these execution contexts together, 91 00:04:39.590 --> 00:04:42.630 make up the call stack that I mentioned before. 92 00:04:42.630 --> 00:04:44.943 But more on that in a second. 93 00:04:45.880 --> 00:04:49.030 Now, when all functions are done executing, 94 00:04:49.030 --> 00:04:51.300 the engine will basically keep waiting 95 00:04:51.300 --> 00:04:53.810 for callback functions to arrive 96 00:04:53.810 --> 00:04:56.150 so that it can execute these. 97 00:04:56.150 --> 00:04:59.130 For example, a callback function associated 98 00:04:59.130 --> 00:05:01.330 with a click event. 99 00:05:01.330 --> 00:05:04.700 And remember, that it's the event loop who provides 100 00:05:04.700 --> 00:05:06.660 these new callback functions 101 00:05:06.660 --> 00:05:08.723 as we learned in the last lecture. 102 00:05:09.630 --> 00:05:10.580 All right. 103 00:05:10.580 --> 00:05:14.150 So we know now what an execution context is, 104 00:05:14.150 --> 00:05:16.930 but don't really know what it's made of. 105 00:05:16.930 --> 00:05:18.970 So, what's inside of it? 106 00:05:18.970 --> 00:05:21.143 And so let's find that out next. 107 00:05:22.490 --> 00:05:26.420 And the first thing that's inside any execution context 108 00:05:26.420 --> 00:05:29.760 is a so-called variable environment. 109 00:05:29.760 --> 00:05:31.120 In this environment, 110 00:05:31.120 --> 00:05:34.920 all our variables and function declarations are stored, 111 00:05:34.920 --> 00:05:38.330 and there is also a special arguments object. 112 00:05:38.330 --> 00:05:39.940 This object contains, 113 00:05:39.940 --> 00:05:43.150 as the name says all the arguments that were passed 114 00:05:43.150 --> 00:05:46.500 into the function that the current execution context 115 00:05:46.500 --> 00:05:47.900 belongs to. 116 00:05:47.900 --> 00:05:50.530 Because remember each function 117 00:05:50.530 --> 00:05:53.110 gets its own execution context 118 00:05:53.110 --> 00:05:56.280 as soon as the function is called. 119 00:05:56.280 --> 00:05:58.380 So basically all the variables 120 00:05:58.380 --> 00:06:01.610 that are somehow declared inside a function, 121 00:06:01.610 --> 00:06:04.830 will end up in its variable environment. 122 00:06:04.830 --> 00:06:08.120 However, a function can also access variables 123 00:06:08.120 --> 00:06:10.210 outside of the function. 124 00:06:10.210 --> 00:06:12.920 And we have already seen that in action 125 00:06:12.920 --> 00:06:14.260 throughout this course, 126 00:06:14.260 --> 00:06:17.830 especially in the projects of the previous section. 127 00:06:17.830 --> 00:06:22.150 And this works because of something called the scope chain. 128 00:06:22.150 --> 00:06:24.040 And we will learn all about scoping 129 00:06:24.040 --> 00:06:26.680 and the scope chain later in the section. 130 00:06:26.680 --> 00:06:28.590 But for now, what you need to know 131 00:06:28.590 --> 00:06:31.850 is that the scope chain basically consists of 132 00:06:31.850 --> 00:06:34.810 references to variables that are located 133 00:06:34.810 --> 00:06:37.440 outside of the current function. 134 00:06:37.440 --> 00:06:39.880 And to keep track of the scope chain, 135 00:06:39.880 --> 00:06:43.260 it is stored in each execution context. 136 00:06:43.260 --> 00:06:47.290 Finally, each context also gets a special variable 137 00:06:47.290 --> 00:06:49.580 called the this keyword. 138 00:06:49.580 --> 00:06:52.110 And once more, there is a special lecture 139 00:06:52.110 --> 00:06:55.960 just about the this keyword later in the section. 140 00:06:55.960 --> 00:06:57.000 Okay. 141 00:06:57.000 --> 00:07:00.270 Now, the content of the execution context, 142 00:07:00.270 --> 00:07:03.490 so variable environment, scope chain 143 00:07:03.490 --> 00:07:08.490 and this keyword is generated in a so-called creation phase. 144 00:07:08.640 --> 00:07:11.453 Which happens right before execution. 145 00:07:12.350 --> 00:07:14.070 And now just one final 146 00:07:14.070 --> 00:07:17.610 but very important detail that we need to keep in mind, 147 00:07:17.610 --> 00:07:22.160 is that execution contexts belonging to arrow functions, 148 00:07:22.160 --> 00:07:25.040 do not get their own arguments keyword, 149 00:07:25.040 --> 00:07:29.420 nor do they get the this keyword, okay? 150 00:07:29.420 --> 00:07:31.530 So, basically arrow functions 151 00:07:31.530 --> 00:07:33.900 don't have the arguments object 152 00:07:33.900 --> 00:07:35.720 and the this keyword. 153 00:07:35.720 --> 00:07:38.570 Instead, they can use the arguments object, 154 00:07:38.570 --> 00:07:39.990 and the this keyword 155 00:07:39.990 --> 00:07:43.740 from their closest regular function parent. 156 00:07:43.740 --> 00:07:46.990 And this is an extremely important detail to remember 157 00:07:46.990 --> 00:07:51.310 about arrow functions and we will come back to it later. 158 00:07:51.310 --> 00:07:52.840 So these are the things 159 00:07:52.840 --> 00:07:56.080 that are necessary to run each function 160 00:07:56.080 --> 00:07:59.300 as well as the code in the top-level. 161 00:07:59.300 --> 00:08:03.250 Now behind the scenes, it's actually even more complex 162 00:08:03.250 --> 00:08:07.250 but I think we're fine like this, aren't we? 163 00:08:07.250 --> 00:08:11.240 And now let's actually try to simulate the creation phase 164 00:08:11.240 --> 00:08:13.810 for this code example here. 165 00:08:13.810 --> 00:08:16.610 So, as you hopefully know, by now, 166 00:08:16.610 --> 00:08:19.710 we will get one global execution context 167 00:08:19.710 --> 00:08:21.670 and one for each function. 168 00:08:21.670 --> 00:08:23.970 So one for the first function, 169 00:08:23.970 --> 00:08:26.970 and one for the second function. 170 00:08:26.970 --> 00:08:28.350 In the global context, 171 00:08:28.350 --> 00:08:31.560 we have the name variable declaration, 172 00:08:31.560 --> 00:08:34.200 the first and second function declarations, 173 00:08:34.200 --> 00:08:37.900 as well as the X variable declaration. 174 00:08:37.900 --> 00:08:40.580 For the functions, the variable environment 175 00:08:40.580 --> 00:08:43.180 will literally contain all the code 176 00:08:43.180 --> 00:08:45.520 of a particular function. 177 00:08:45.520 --> 00:08:49.530 Now the value of X is marked as unknown here, 178 00:08:49.530 --> 00:08:51.950 because this value is the result 179 00:08:51.950 --> 00:08:55.350 of the first function that we didn't run yet. 180 00:08:55.350 --> 00:08:58.810 But we will simulate this in the next slide. 181 00:08:58.810 --> 00:09:03.120 Now, technically none of these values actually become known 182 00:09:03.120 --> 00:09:07.670 during the creation phase, but only in the execution phase. 183 00:09:07.670 --> 00:09:10.660 So this is not 100% accurate here, 184 00:09:10.660 --> 00:09:12.850 but it's just to illustrate 185 00:09:12.850 --> 00:09:15.760 how these execution contexts work. 186 00:09:15.760 --> 00:09:18.750 Okay? So just keep that in mind. 187 00:09:18.750 --> 00:09:21.270 Anyway, now in the first function, 188 00:09:21.270 --> 00:09:25.430 we have the a variable set to 1 and the b variable 189 00:09:25.430 --> 00:09:28.350 which once again requires a function call 190 00:09:28.350 --> 00:09:30.620 in order to become known. 191 00:09:30.620 --> 00:09:34.550 Finally, the variable environment of the second function, 192 00:09:34.550 --> 00:09:37.470 contains the C variable set to 2, 193 00:09:37.470 --> 00:09:40.300 and since this is a irregular function, 194 00:09:40.300 --> 00:09:45.300 so not an arrow function, it also has the arguments object. 195 00:09:45.730 --> 00:09:48.010 And this object is an array, 196 00:09:48.010 --> 00:09:51.160 which contains all the arguments that were passed 197 00:09:51.160 --> 00:09:53.830 into the function when it was called. 198 00:09:53.830 --> 00:09:58.270 In this case, as you can see, that's 7 and 9. 199 00:09:58.270 --> 00:10:00.380 Quite simple right? 200 00:10:00.380 --> 00:10:04.180 Well, it's simple because this is an extremely small 201 00:10:04.180 --> 00:10:05.660 amount of code. 202 00:10:05.660 --> 00:10:09.500 But now imagine there are hundreds of execution contexts 203 00:10:09.500 --> 00:10:11.680 for hundreds of functions. 204 00:10:11.680 --> 00:10:13.800 How will the engine keep track 205 00:10:13.800 --> 00:10:17.020 of the order in which functions we're called? 206 00:10:17.020 --> 00:10:19.890 And how will it know where it currently is 207 00:10:19.890 --> 00:10:21.750 in the execution? 208 00:10:21.750 --> 00:10:25.403 Well, that's where the call stack finally comes in. 209 00:10:26.530 --> 00:10:28.500 And remember that the call stack, 210 00:10:28.500 --> 00:10:30.710 together with the memory heap, 211 00:10:30.710 --> 00:10:33.950 makes up the JavaScript engine itself. 212 00:10:33.950 --> 00:10:37.270 But what actually is the call stack? 213 00:10:37.270 --> 00:10:41.440 Well, it's basically a place where execution contexts 214 00:10:41.440 --> 00:10:44.450 get stacked on top of each other, 215 00:10:44.450 --> 00:10:45.770 in order to keep track 216 00:10:45.770 --> 00:10:49.564 of where we are in the programs execution. 217 00:10:49.564 --> 00:10:53.190 So the execution context that is on top of the stack, 218 00:10:53.190 --> 00:10:55.660 is the one that is currently running. 219 00:10:55.660 --> 00:10:57.400 And when it's finished running, 220 00:10:57.400 --> 00:10:59.620 it will be removed from the stack, 221 00:10:59.620 --> 00:11:01.400 and execution will go back 222 00:11:01.400 --> 00:11:04.270 to the previous execution context. 223 00:11:04.270 --> 00:11:06.780 And using the analogy from before, 224 00:11:06.780 --> 00:11:10.470 it is as if you bought pizzas with some friends. 225 00:11:10.470 --> 00:11:14.540 Each friend has a pizza box, and then you put the boxes 226 00:11:14.540 --> 00:11:17.490 on top of each other, forming a stack, 227 00:11:17.490 --> 00:11:21.093 in order to keep track, which pizza belongs to each friend. 228 00:11:21.980 --> 00:11:25.450 Now, all this sounds a bit abstract, doesn't it? 229 00:11:25.450 --> 00:11:28.480 And so to demonstrate how the call stack works, 230 00:11:28.480 --> 00:11:31.760 let's walk through this code example together, 231 00:11:31.760 --> 00:11:35.520 so that I can show you exactly what happens. 232 00:11:35.520 --> 00:11:38.200 So, once the code is compiled, 233 00:11:38.200 --> 00:11:41.510 top-level code will start execution. 234 00:11:41.510 --> 00:11:44.690 And then as we learned in the beginning of the lecture, 235 00:11:44.690 --> 00:11:47.940 a global execution context will be created 236 00:11:47.940 --> 00:11:50.850 for the top-level of code, right? 237 00:11:50.850 --> 00:11:54.260 So this is where all the code outside of any function 238 00:11:54.260 --> 00:11:56.270 will be executed. 239 00:11:56.270 --> 00:11:59.800 And what happens with this execution context? 240 00:11:59.800 --> 00:12:03.113 That's right, it will be put in the call stack. 241 00:12:04.120 --> 00:12:07.980 And since this context is now at the top of the stack, 242 00:12:07.980 --> 00:12:12.370 it is the one where the code is currently being executed. 243 00:12:12.370 --> 00:12:16.120 So, let's continue now with this execution. 244 00:12:16.120 --> 00:12:19.990 So here, there is a simple variable declaration. 245 00:12:19.990 --> 00:12:24.990 And then the first and the second functions are declared. 246 00:12:25.200 --> 00:12:29.950 So nothing fancy, but that's just how normal top-level code 247 00:12:29.950 --> 00:12:31.640 gets executed. 248 00:12:31.640 --> 00:12:33.930 But then, in the last line 249 00:12:33.930 --> 00:12:36.750 is where things start to get interesting. 250 00:12:36.750 --> 00:12:39.320 Here, we declare the X variable, 251 00:12:39.320 --> 00:12:41.840 with the value that is gonna be returned 252 00:12:41.840 --> 00:12:44.460 from calling the first function. 253 00:12:44.460 --> 00:12:47.383 And so let's actually call that function. 254 00:12:48.600 --> 00:12:52.430 Now what happens immediately when a function is called? 255 00:12:52.430 --> 00:12:55.920 Well, it gets its own execution context 256 00:12:55.920 --> 00:13:00.270 so that it can run the code that's inside its body. 257 00:13:00.270 --> 00:13:01.270 Perfect. 258 00:13:01.270 --> 00:13:03.690 And what happens to the context? 259 00:13:03.690 --> 00:13:07.200 Well, again it is put in the call stack, 260 00:13:07.200 --> 00:13:09.540 on top of the current context, 261 00:13:09.540 --> 00:13:13.640 and so it's now the new current execution context. 262 00:13:13.640 --> 00:13:14.473 Great. 263 00:13:14.473 --> 00:13:16.290 So, let's continue. 264 00:13:16.290 --> 00:13:20.010 So we have yet another simple variable declaration here, 265 00:13:20.010 --> 00:13:22.770 and this variable will of course be defined 266 00:13:22.770 --> 00:13:24.420 in the variable environment 267 00:13:24.420 --> 00:13:26.520 of the current execution context, 268 00:13:26.520 --> 00:13:29.950 and not in the global context, right? 269 00:13:29.950 --> 00:13:34.610 Then right in the next line, we have another function call. 270 00:13:34.610 --> 00:13:38.210 So, let's call that function and move there. 271 00:13:38.210 --> 00:13:41.030 And as you guessed a new execution context 272 00:13:41.030 --> 00:13:45.100 was created right away for this second function. 273 00:13:45.100 --> 00:13:46.990 And once more, it is pushed 274 00:13:46.990 --> 00:13:51.450 onto the call stack and becomes the new act of context. 275 00:13:51.450 --> 00:13:54.920 Now what's important to note here is that the execution 276 00:13:54.920 --> 00:13:59.420 of the first function has now been paused, okay? 277 00:13:59.420 --> 00:14:03.000 So again, we are running the second function now 278 00:14:03.000 --> 00:14:07.420 and in the meantime, no other function is being executed. 279 00:14:07.420 --> 00:14:10.170 The first function stopped at this point 280 00:14:10.170 --> 00:14:12.220 where the second function was called 281 00:14:12.220 --> 00:14:14.310 and will only continue as soon 282 00:14:14.310 --> 00:14:17.240 as this second function returns. 283 00:14:17.240 --> 00:14:21.080 And it has to work this way because remember, 284 00:14:21.080 --> 00:14:24.650 JavaScript has only one thread of execution. 285 00:14:24.650 --> 00:14:27.890 And so it can only do one thing at a time. 286 00:14:27.890 --> 00:14:30.463 Okay? Never forget that. 287 00:14:31.500 --> 00:14:36.500 Now, moving to the next line, we have a return statement 288 00:14:36.690 --> 00:14:40.670 meaning that the function will finish its execution. 289 00:14:40.670 --> 00:14:44.350 So, what does that mean for the call stack? 290 00:14:44.350 --> 00:14:45.970 Well, it basically means 291 00:14:45.970 --> 00:14:48.430 that the function's execution context, 292 00:14:48.430 --> 00:14:50.740 will be popped off the stack 293 00:14:50.740 --> 00:14:53.920 and disappear from the computer's memory. 294 00:14:53.920 --> 00:14:56.580 At least that's what you need to know for now 295 00:14:56.580 --> 00:15:00.060 because actually the popped off execution context 296 00:15:00.060 --> 00:15:02.250 might keep living in memory. 297 00:15:02.250 --> 00:15:05.300 But more about that later in the course. 298 00:15:05.300 --> 00:15:07.460 Anyway, what happens next, 299 00:15:07.460 --> 00:15:11.100 is that the previous execution context, will now be back 300 00:15:11.100 --> 00:15:14.740 to being the active execution context again. 301 00:15:14.740 --> 00:15:17.930 And so let's also go back to where we were 302 00:15:17.930 --> 00:15:20.340 before in the code. 303 00:15:20.340 --> 00:15:21.890 And I hope that by now, 304 00:15:21.890 --> 00:15:25.400 you start to see how the call stack really keeps track 305 00:15:25.400 --> 00:15:28.260 of the order of execution here. 306 00:15:28.260 --> 00:15:29.770 Without the call stack, 307 00:15:29.770 --> 00:15:32.180 how would the engine know which function 308 00:15:32.180 --> 00:15:34.410 was being executed before? 309 00:15:34.410 --> 00:15:38.180 It wouldn't know where to go back to, right? 310 00:15:38.180 --> 00:15:40.570 And that's the beauty of the call stack. 311 00:15:40.570 --> 00:15:44.030 It makes this process almost effortless. 312 00:15:44.030 --> 00:15:45.900 So I like to use the analogy 313 00:15:45.900 --> 00:15:49.070 of the call stack being like a map 314 00:15:49.070 --> 00:15:50.940 for the JavaScript engine. 315 00:15:50.940 --> 00:15:53.150 Because the call stack ensures 316 00:15:53.150 --> 00:15:56.760 that the order of execution never gets lost. 317 00:15:56.760 --> 00:16:01.200 Just like a map does, at least if you use it correctly. 318 00:16:01.200 --> 00:16:02.090 All right. 319 00:16:02.090 --> 00:16:05.080 So, we returned from the second function, 320 00:16:05.080 --> 00:16:06.990 or back in the first function 321 00:16:06.990 --> 00:16:09.580 where we have this calculation, 322 00:16:09.580 --> 00:16:13.730 and then finally this first function also returns. 323 00:16:13.730 --> 00:16:16.780 And so here the same as before happens. 324 00:16:16.780 --> 00:16:21.320 So the current execution context gets popped off the stack, 325 00:16:21.320 --> 00:16:25.030 and the previous context is now the current context 326 00:16:25.030 --> 00:16:27.440 where code is executed. 327 00:16:27.440 --> 00:16:31.540 In this case, we're back to the global execution context 328 00:16:31.540 --> 00:16:34.330 and the line of code where the first function 329 00:16:34.330 --> 00:16:36.100 was first called. 330 00:16:36.100 --> 00:16:40.290 So here, the return value is finally assigned to X 331 00:16:40.290 --> 00:16:42.713 and the execution is finished. 332 00:16:43.640 --> 00:16:47.230 Now the program will now actually stay in this state 333 00:16:47.230 --> 00:16:51.420 for forever until it is eventually really finished. 334 00:16:51.420 --> 00:16:55.040 And that only happens like when we close the browser tab, 335 00:16:55.040 --> 00:16:56.580 or the browser window. 336 00:16:56.580 --> 00:17:00.110 Only when the program is really finished like this, 337 00:17:00.110 --> 00:17:02.750 is when the global execution context 338 00:17:02.750 --> 00:17:05.750 is also popped off the stack. 339 00:17:05.750 --> 00:17:10.750 And this is in a nutshell how the call stack works. 340 00:17:10.770 --> 00:17:13.890 So hopefully it makes sense now that we say 341 00:17:13.890 --> 00:17:17.370 that Java script code runs inside the call stack. 342 00:17:17.370 --> 00:17:19.830 And actually it is more accurate to say 343 00:17:19.830 --> 00:17:23.480 that code runs inside of execution contexts 344 00:17:23.480 --> 00:17:25.020 that are in the stack. 345 00:17:25.020 --> 00:17:29.090 But the general point is that code runs in the call stack, 346 00:17:29.090 --> 00:17:30.853 which is of course true. 347 00:17:31.720 --> 00:17:32.670 Great. 348 00:17:32.670 --> 00:17:34.850 Next up, we will learn some more 349 00:17:34.850 --> 00:17:37.310 about the variable environment, 350 00:17:37.310 --> 00:17:39.890 and how variables are created. 351 00:17:39.890 --> 00:17:42.893 So stay tuned for the next video.