1 00:00:01,120 --> 00:00:03,650 So I talked about the JavaScript engine 2 00:00:03,650 --> 00:00:08,040 in the last lecture, but what is that engine actually? 3 00:00:08,040 --> 00:00:10,830 And what is a JavaScript runtime? 4 00:00:10,830 --> 00:00:15,700 Also, how is JavaScript code translated to a machine code? 5 00:00:15,700 --> 00:00:17,470 So that's just some of the topics 6 00:00:17,470 --> 00:00:19,550 that we talked about in the last video. 7 00:00:19,550 --> 00:00:23,483 And so now let's find out how they work in this lecture. 8 00:00:24,900 --> 00:00:27,660 So a JavaScript engine is simply 9 00:00:27,660 --> 00:00:31,740 a computer program that executes JavaScript code. 10 00:00:31,740 --> 00:00:35,080 There are a lot of steps involved in doing that, 11 00:00:35,080 --> 00:00:38,050 but essentially executing JavaScript code 12 00:00:38,050 --> 00:00:40,590 is what an engine does. 13 00:00:40,590 --> 00:00:44,200 Now every browser has its own JavaScript engine 14 00:00:44,200 --> 00:00:49,090 but probably the most well known engine is Google's V-Eight. 15 00:00:49,090 --> 00:00:51,720 The V eight engine powers Google Chrome, 16 00:00:51,720 --> 00:00:55,730 but also Node.js which is that JavaScript runtime 17 00:00:55,730 --> 00:00:58,630 that we talked about in the beginning of the course, 18 00:00:58,630 --> 00:01:02,560 so the one that we can use to build server side applications 19 00:01:02,560 --> 00:01:06,990 with JavaScript, so outside of any browser. 20 00:01:06,990 --> 00:01:09,290 And of course all the other browsers 21 00:01:09,290 --> 00:01:11,510 have their own JavaScript engines 22 00:01:11,510 --> 00:01:15,310 which you can look up online if you're interested. 23 00:01:15,310 --> 00:01:19,430 Anyway, it's quite easy to understand what an engine is 24 00:01:19,430 --> 00:01:22,610 but what's most important is to actually understand 25 00:01:22,610 --> 00:01:25,900 its components and how it works. 26 00:01:25,900 --> 00:01:29,030 So any JavaScript engine always contains 27 00:01:29,030 --> 00:01:32,040 a call stack and a heap. 28 00:01:32,040 --> 00:01:36,250 The call stack is where our code is actually executed 29 00:01:36,250 --> 00:01:39,149 using something called execution contexts. 30 00:01:39,149 --> 00:01:42,880 Then the heap is an unstructured memory pool 31 00:01:42,880 --> 00:01:47,420 which stores all the objects that our application needs. 32 00:01:47,420 --> 00:01:50,770 Alright, so with this look at the engine, 33 00:01:50,770 --> 00:01:54,080 we have answered where our code is executed. 34 00:01:54,080 --> 00:01:55,670 But now the question is 35 00:01:55,670 --> 00:01:58,830 how the code is compiled to machine code 36 00:01:58,830 --> 00:02:02,560 so that it actually can be executed afterwards. 37 00:02:02,560 --> 00:02:04,403 Well, let's find out. 38 00:02:05,600 --> 00:02:07,040 But first we need to make 39 00:02:07,040 --> 00:02:09,780 a quick computer science side note here 40 00:02:09,780 --> 00:02:11,550 and talk about the difference between 41 00:02:11,550 --> 00:02:14,530 compilation and interpretation. 42 00:02:14,530 --> 00:02:15,900 So in the last lecture, 43 00:02:15,900 --> 00:02:18,660 we learned that the computer's processor 44 00:02:18,660 --> 00:02:21,630 only understands zeros and ones 45 00:02:21,630 --> 00:02:25,040 and that's therefore every single computer program 46 00:02:25,040 --> 00:02:29,220 ultimately needs to be converted into this machine code 47 00:02:29,220 --> 00:02:33,860 and this can happen using compilation or interpretation. 48 00:02:33,860 --> 00:02:36,880 So in compilation, the entire source code 49 00:02:36,880 --> 00:02:39,890 is converted into machine code at once. 50 00:02:39,890 --> 00:02:42,520 And this machine code is then written 51 00:02:42,520 --> 00:02:47,440 into a portable file that can be executed on any computer. 52 00:02:47,440 --> 00:02:49,980 So we have two different steps here. 53 00:02:49,980 --> 00:02:52,200 First, the machine code is built 54 00:02:52,200 --> 00:02:56,870 and then it is executed in the CPU so in the processor. 55 00:02:56,870 --> 00:02:58,510 And the execution can happen 56 00:02:58,510 --> 00:03:01,390 way after the compilation of course. 57 00:03:01,390 --> 00:03:04,080 For example, any application that you're using 58 00:03:04,080 --> 00:03:08,210 on your computer right now has been compiled before 59 00:03:08,210 --> 00:03:11,883 and you're now executing it way after it's compilation. 60 00:03:12,740 --> 00:03:15,960 Now, on the other hand in interpretation, 61 00:03:15,960 --> 00:03:19,990 there is an interpreter which runs through the source code 62 00:03:19,990 --> 00:03:22,840 and executes it line by line. 63 00:03:22,840 --> 00:03:27,010 So here we do not have the same two steps as before. 64 00:03:27,010 --> 00:03:32,010 Instead the code is read and executed all at the same time. 65 00:03:32,230 --> 00:03:34,650 Of course the source code still 66 00:03:34,650 --> 00:03:37,430 needs to be converted into machine code, 67 00:03:37,430 --> 00:03:40,810 but it simply happens right before it's executed 68 00:03:40,810 --> 00:03:43,320 and not ahead of time. 69 00:03:43,320 --> 00:03:47,580 Now JavaScript used to be a purely interpreted language 70 00:03:47,580 --> 00:03:50,170 but the problem with interpreted languages 71 00:03:50,170 --> 00:03:54,630 is that they are much, much slower than compiled languages. 72 00:03:54,630 --> 00:03:57,450 This used to be okay for JavaScript, 73 00:03:57,450 --> 00:03:59,770 but now with modern JavaScript 74 00:03:59,770 --> 00:04:02,890 and fully fledged web applications that we built 75 00:04:02,890 --> 00:04:07,890 and use today, low performance is no longer acceptable. 76 00:04:07,930 --> 00:04:11,050 Just imagine you were using Google maps in your browser 77 00:04:11,050 --> 00:04:14,200 and you were dragging the map and each time you dragged 78 00:04:14,200 --> 00:04:17,370 it would take one second for it to move. 79 00:04:17,370 --> 00:04:20,815 That would be completely unacceptable, right? 80 00:04:20,815 --> 00:04:23,060 Now many people still think 81 00:04:23,060 --> 00:04:25,760 that JavaScript is an interpreted language 82 00:04:25,760 --> 00:04:28,410 but that's not really true anymore. 83 00:04:28,410 --> 00:04:31,380 So instead of simple interpretation 84 00:04:31,380 --> 00:04:34,690 modern JavaScript engine now use a mix between 85 00:04:34,690 --> 00:04:37,370 compilation and interpretation 86 00:04:37,370 --> 00:04:41,140 which is called just-in-time compilation. 87 00:04:41,140 --> 00:04:44,130 This approach basically compiles the entire code 88 00:04:44,130 --> 00:04:48,830 into machine code at once and then executes it right away. 89 00:04:48,830 --> 00:04:50,680 So we still have the two steps 90 00:04:50,680 --> 00:04:53,960 of regular ahead of time compilation 91 00:04:53,960 --> 00:04:57,240 but there is no portable file to execute. 92 00:04:57,240 --> 00:05:01,720 And the execution happens immediately after a compilation. 93 00:05:01,720 --> 00:05:04,370 And this is perfect for JavaScript 94 00:05:04,370 --> 00:05:08,350 as it's really a lot faster than just executing code 95 00:05:08,350 --> 00:05:10,250 line by line. 96 00:05:10,250 --> 00:05:13,360 Now I skimmed over some details here 97 00:05:13,360 --> 00:05:16,120 but this is really all you need to know. 98 00:05:16,120 --> 00:05:19,130 Anyway, let's now understand how this works 99 00:05:19,130 --> 00:05:22,023 in the particular case of JavaScript. 100 00:05:23,840 --> 00:05:27,627 So as a piece of JavaScript code enters the engine 101 00:05:27,627 --> 00:05:31,040 the first step is to parse the code 102 00:05:31,040 --> 00:05:34,400 which essentially means to read the code. 103 00:05:34,400 --> 00:05:37,850 During the parsing process, the code is parsed 104 00:05:37,850 --> 00:05:39,850 into a data structure called 105 00:05:39,850 --> 00:05:43,630 the abstract syntax tree or AST. 106 00:05:43,630 --> 00:05:46,670 This works by first splitting up each line of code 107 00:05:46,670 --> 00:05:49,730 into pieces that are meaningful to the language 108 00:05:49,730 --> 00:05:52,490 like the const or function keywords, 109 00:05:52,490 --> 00:05:54,500 and then saving all these pieces 110 00:05:54,500 --> 00:05:57,570 into the tree in a structured way. 111 00:05:57,570 --> 00:06:01,590 This step also checks if there are any syntax errors 112 00:06:01,590 --> 00:06:04,250 and the resulting tree will later be used 113 00:06:04,250 --> 00:06:06,840 to generate the machine code. 114 00:06:06,840 --> 00:06:09,890 Now let's say we have a very simple program. 115 00:06:09,890 --> 00:06:13,800 All it does is to declare a variable like this, 116 00:06:13,800 --> 00:06:15,900 and this is what the AST 117 00:06:15,900 --> 00:06:19,560 for just this one line of code looks like. 118 00:06:19,560 --> 00:06:21,900 So we have a variable declaration 119 00:06:21,900 --> 00:06:23,900 which should be a constant 120 00:06:23,900 --> 00:06:28,500 with the name X and the value of 23. 121 00:06:28,500 --> 00:06:32,050 And besides that there is a lot of other stuff here, 122 00:06:32,050 --> 00:06:33,620 as you can see. 123 00:06:33,620 --> 00:06:35,930 So just imagine what it would look like 124 00:06:35,930 --> 00:06:38,910 for a large real application. 125 00:06:38,910 --> 00:06:41,230 And of course you don't need to know 126 00:06:41,230 --> 00:06:43,520 what an AST looks like. 127 00:06:43,520 --> 00:06:46,990 This is just for curiosity okay. 128 00:06:46,990 --> 00:06:48,850 Now sometimes I get asked 129 00:06:48,850 --> 00:06:53,030 if this tree has anything to do with the DOM tree 130 00:06:53,030 --> 00:06:56,220 and the answer is a very clear no. 131 00:06:56,220 --> 00:07:00,550 So this tree has absolutely nothing to do with the DOM. 132 00:07:00,550 --> 00:07:03,310 It is not related in any way. 133 00:07:03,310 --> 00:07:05,060 It's just a representation 134 00:07:05,060 --> 00:07:08,662 of our entire code inside the engine. 135 00:07:08,662 --> 00:07:11,940 Anyway, the next step is compilation 136 00:07:11,940 --> 00:07:14,610 which takes the generated AST 137 00:07:14,610 --> 00:07:17,330 and compiles it into machine code 138 00:07:17,330 --> 00:07:20,290 just as we learned in the previous slide. 139 00:07:20,290 --> 00:07:24,100 This machine code then gets executed right away 140 00:07:24,100 --> 00:07:27,720 because remember modern JavaScript engine use 141 00:07:27,720 --> 00:07:30,180 just-in-time compilation. 142 00:07:30,180 --> 00:07:32,770 And remember execution happens 143 00:07:32,770 --> 00:07:35,670 in the JavaScript engines call stack 144 00:07:35,670 --> 00:07:39,600 but we will dig deeper into this in the next lecture. 145 00:07:39,600 --> 00:07:42,210 All right, so far so good. 146 00:07:42,210 --> 00:07:46,180 We have our code running so we can finish here, Right? 147 00:07:46,180 --> 00:07:50,120 Well, not so fast because modern JavaScript engines 148 00:07:50,120 --> 00:07:54,110 actually have some pretty clever optimization strategies. 149 00:07:54,110 --> 00:07:57,870 What they do is to create a very unoptimized version 150 00:07:57,870 --> 00:07:59,800 of machine code in the beginning 151 00:07:59,800 --> 00:08:04,400 just so that it can start executing as fast as possible. 152 00:08:04,400 --> 00:08:07,840 Then in the background, this code is being optimized 153 00:08:07,840 --> 00:08:12,840 and recompiled during the already running program execution. 154 00:08:12,900 --> 00:08:15,060 And this can be done most of the times 155 00:08:15,060 --> 00:08:17,170 and after each optimization 156 00:08:17,170 --> 00:08:20,240 the unoptimized code is simply swept 157 00:08:20,240 --> 00:08:22,790 for the new more optimized code 158 00:08:22,790 --> 00:08:26,000 without ever stopping execution of course. 159 00:08:26,000 --> 00:08:29,300 And this process is what makes modern engines 160 00:08:29,300 --> 00:08:32,720 such as the V-Eight so fast 161 00:08:32,720 --> 00:08:36,480 and all this parsing, compilation and optimization 162 00:08:36,480 --> 00:08:40,183 happens in some special threads inside the engine 163 00:08:40,183 --> 00:08:42,730 that we cannot access from our code. 164 00:08:42,730 --> 00:08:45,850 So completely separate from the main thread 165 00:08:45,850 --> 00:08:48,310 that is basically running into call stack 166 00:08:48,310 --> 00:08:50,910 executing our own code. 167 00:08:50,910 --> 00:08:55,250 Now different engines implements in slightly different ways, 168 00:08:55,250 --> 00:08:58,220 but in a nutshell this is what modern 169 00:08:58,220 --> 00:09:02,700 just-in-time compilation looks like for JavaScript. 170 00:09:02,700 --> 00:09:04,720 And the next time someone tells you 171 00:09:04,720 --> 00:09:07,490 JavaScript is an interpreted language, 172 00:09:07,490 --> 00:09:10,550 you just show them this slide so that they can learn 173 00:09:10,550 --> 00:09:12,053 how it really works. 174 00:09:13,280 --> 00:09:16,720 Alright, so we looked at the JavaScript engine 175 00:09:16,720 --> 00:09:20,740 and how it works behind the scenes in quite some detail. 176 00:09:20,740 --> 00:09:23,060 Now to round off this lecture 177 00:09:23,060 --> 00:09:27,050 let's also take a look at what a JavaScript runtime is. 178 00:09:27,050 --> 00:09:29,680 And in particular, the most common one, 179 00:09:29,680 --> 00:09:32,470 which is the browser and by doing this, 180 00:09:32,470 --> 00:09:34,200 we can get the bigger picture 181 00:09:34,200 --> 00:09:38,750 of how all the pieces fit together when we use JavaScript. 182 00:09:38,750 --> 00:09:41,560 And so this is a really important slide. 183 00:09:41,560 --> 00:09:46,480 So we can imagine a JavaScript runtime as a big box 184 00:09:46,480 --> 00:09:48,250 or a big container 185 00:09:48,250 --> 00:09:50,860 which includes all the things that we need 186 00:09:50,860 --> 00:09:55,330 in order to use JavaScript in this case, in the browser. 187 00:09:55,330 --> 00:09:58,197 And to heart of any JavaScript, 188 00:09:58,197 --> 00:10:01,120 runtime is always a JavaScript engine. 189 00:10:01,120 --> 00:10:04,490 So exactly the one we've been talking about. 190 00:10:04,490 --> 00:10:07,570 That's why it makes sense to talk about engines 191 00:10:07,570 --> 00:10:09,690 and runtimes together. 192 00:10:09,690 --> 00:10:12,510 Without an engine there is no runtime 193 00:10:12,510 --> 00:10:15,710 and there is no JavaScript at all. 194 00:10:15,710 --> 00:10:19,500 However the engine alone is not enough. 195 00:10:19,500 --> 00:10:21,470 In order to work properly, 196 00:10:21,470 --> 00:10:24,990 we also need access to the web APIs, 197 00:10:24,990 --> 00:10:28,480 and we talked about web APIs before, remember? 198 00:10:28,480 --> 00:10:31,160 So that's everything related to the DOM 199 00:10:31,160 --> 00:10:36,160 or timers or even the console.log that we use all the time. 200 00:10:36,420 --> 00:10:40,890 So essentially web APIs are functionalities provided 201 00:10:40,890 --> 00:10:42,200 to the engine, 202 00:10:42,200 --> 00:10:44,450 but which are actually not part 203 00:10:44,450 --> 00:10:47,060 of the JavaScript language itself. 204 00:10:47,060 --> 00:10:50,550 JavaScript simply gets access to these APIs 205 00:10:50,550 --> 00:10:53,020 through the global window object. 206 00:10:53,020 --> 00:10:55,720 But it still makes sense that the web APIs 207 00:10:55,720 --> 00:10:58,170 are also part of the runtime, 208 00:10:58,170 --> 00:11:02,460 because again a runtime is just like a box 209 00:11:02,460 --> 00:11:07,050 that contains all the JavaScript related stuff that we need. 210 00:11:07,050 --> 00:11:09,640 Next a typical JavaScript runtime 211 00:11:09,640 --> 00:11:13,300 also includes a so called callback queue. 212 00:11:13,300 --> 00:11:15,840 This is a data structure that contains 213 00:11:15,840 --> 00:11:20,180 all the callback functions that are ready to be executed. 214 00:11:20,180 --> 00:11:23,350 For example we attach event handler functions 215 00:11:23,350 --> 00:11:26,010 to DOM elements like a button 216 00:11:26,010 --> 00:11:28,860 to react to certain events, right? 217 00:11:28,860 --> 00:11:30,700 And these event handler functions 218 00:11:30,700 --> 00:11:34,540 are also called callback functions okay. 219 00:11:34,540 --> 00:11:36,570 So as the event happens, 220 00:11:36,570 --> 00:11:40,900 for example a click, the callback function will be called. 221 00:11:40,900 --> 00:11:44,240 And here is how that actually works behind the scenes. 222 00:11:44,240 --> 00:11:47,900 So the first thing that actually happens after the event 223 00:11:47,900 --> 00:11:50,310 is that the callback function is put 224 00:11:50,310 --> 00:11:52,340 into the callback queue. 225 00:11:52,340 --> 00:11:54,430 Then when the stack is empty 226 00:11:54,430 --> 00:11:57,980 the callback function is passed to the stack 227 00:11:57,980 --> 00:12:00,690 so that it can be executed. 228 00:12:00,690 --> 00:12:04,430 And this happens by something called the event loop. 229 00:12:04,430 --> 00:12:07,430 So basically the event loop takes callback functions 230 00:12:07,430 --> 00:12:08,960 from the callback queue 231 00:12:08,960 --> 00:12:11,150 and puts them in the call stack 232 00:12:11,150 --> 00:12:13,850 so that they can be executed. 233 00:12:13,850 --> 00:12:16,570 And remember how I said in the last lecture 234 00:12:16,570 --> 00:12:17,550 that the event loop 235 00:12:17,550 --> 00:12:21,000 is how JavaScript's nonblocking concurrency model 236 00:12:21,000 --> 00:12:22,740 is implemented? 237 00:12:22,740 --> 00:12:26,830 Well, here is an overview of how that works. 238 00:12:26,830 --> 00:12:31,380 Now we will go over why this makes JavaScript nonblocking 239 00:12:31,380 --> 00:12:33,900 in a special lecture about the event loop 240 00:12:33,900 --> 00:12:35,200 later in the course, 241 00:12:35,200 --> 00:12:37,760 because this is really a fundamental piece 242 00:12:37,760 --> 00:12:39,770 of JavaScript development 243 00:12:39,770 --> 00:12:43,083 that every developer needs to understand deeply. 244 00:12:44,180 --> 00:12:48,560 Alright, so as they already said the focus in this course 245 00:12:48,560 --> 00:12:51,100 is on JavaScript in the browser 246 00:12:51,100 --> 00:12:55,660 and that's why we analyzed the browser JavaScript runtime. 247 00:12:55,660 --> 00:12:58,120 However, it's also important to remember 248 00:12:58,120 --> 00:13:01,630 that JavaScript can exist outside of browsers, 249 00:13:01,630 --> 00:13:03,830 for example, in Node.js. 250 00:13:03,830 --> 00:13:07,440 And so here is what the node JS JavaScript runtime 251 00:13:07,440 --> 00:13:08,880 looks like. 252 00:13:08,880 --> 00:13:12,300 It's pretty similar, but since we don't have a browser 253 00:13:12,300 --> 00:13:15,360 of course, we can't have the web APIs 254 00:13:15,360 --> 00:13:18,450 because it's the browser who provides these. 255 00:13:18,450 --> 00:13:21,970 Instead we have multiple C ++ bindings 256 00:13:21,970 --> 00:13:24,570 and a so called thread pool. 257 00:13:24,570 --> 00:13:27,110 Now details don't matter here at all. 258 00:13:27,110 --> 00:13:28,470 I just want you to know 259 00:13:28,470 --> 00:13:32,200 that different JavaScript runtimes do exist. 260 00:13:32,200 --> 00:13:35,460 Alright cool, that's all I had to tell you 261 00:13:35,460 --> 00:13:39,010 about JavaScript engines and runtimes. 262 00:13:39,010 --> 00:13:43,260 In our next lecture we will learn how JavaScript is executed 263 00:13:43,260 --> 00:13:44,533 in the call stack.