JavaScript Under The Hood [5] - JavaScript Engine Overview

Key Takeaways

what's going on guys welcome to part five of JavaScript under the hood so in this video we're gonna have a look at JavaScript engines now we've talked about things like the threat of execution and the call stack and and all of this does happen within the JavaScript engine however what I want to focus on in this video is what happens when your source code is actually interpreted and executed what are the stages that it goes through to get to being machine code that runs on the CPU okay and we'll also look at the different engines that each browser uses all right so let's go ahead and get into it foreign guys so all browsers have a JavaScript engine which essentially is a software component in the JavaScript runtime environment that interprets optimizes and executes JavaScript code now the first engines were just mere interpreters but modern engines are much more intricate and do a lot more optimization including something called jit or just-in-time compilation to increase performance and I'll talk more about this later now most engines are written in languages like C and C plus plus different browsers use different engines they all essentially pretty much do the same thing at a high level but they do differ in their approach and I'll mostly be talking about the V8 engine that Google Chrome uses and that node.js uses when I talk about the inner workings so let's just quickly look at the different engines that each browser uses so Mozilla Firefox uses spider monkey which was actually the the very first JavaScript engine created and it was created by the creator of JavaScript itself Brendan Ike or Brendan ack I'm not exactly sure how to pronounce it but it was used in the Netscape Navigator browser for those of you that are old enough to remember that as I am and then later on it was open sourced and is now is currently maintained by the Mozilla foundation and then the V8 engine is what Google Chrome uses as well as node.js it's extremely fast I believe it's the fastest JavaScript engine don't quote me on that but I'm pretty sure I've heard that multiple times it can be it can run Standalone or it can be embedded into a c plus application and of course it's used with node.js which is a JavaScript runtime that lets us run JavaScript on the server next we have chakra which is what Microsoft Edge uses and Internet Explorer also used an engine called chakra but it was actually a jscript engine jscript was Microsoft's Legacy dialect of the ecmascript standard so it's basically like Microsoft's version of JavaScript one unique feature of chakra is that it compiles scripts on a separate CPU core parallel to the web browser and then Safari uses something called JavaScript core along with a bunch of other Apple applications and Safari you also uses a rendering engine called webkit and all webkit browsers use the JavaScript core engine it provides the ability to evaluate JavaScript programs from within Swift Objective C and C based apps all right so those are the major browsers and the engines that they use now before we look at the inner workings of the JavaScript engine I just want to talk about compiling versus interpreting I'll compile languages versus interpreted languages so JavaScript is what we call and interpret the language and then languages like C and C plus plus these are compile languages now compile languages means you you write the code you run the code through a compiler and it and it turns it into something called machine code and this is usually represented with ones and zeros and a computer or I should say a CPU doesn't directly understand JavaScript or even C or C plus plus it only understands machine code now since languages like C and C plus plus are directly compiled to machine code they're extremely fast and Powerful you know they they do have that extra step of compilation but that only happens once and then your compile code is executed from there on all right now with an interpreted language like JavaScript or python or Ruby the code is not directly compiled into machine code at least not all at once so you don't have that extra step Instead The Interpreter reads your code line line by line checking for errors and runs the program simultaneously so it interprets statements into machine code and statements include source code pre-compile code and scripts so at the end of the day we always end up with machine code but the way we get there is different now the analogy that I I thought of and I think makes sense at least to me is if you were in a foreign country and you needed to have a conversation with someone you know that spoke a different language compiling is like stopping and taking the time to learn the entire language and interpreting would be like having someone there to interpret each word or each sentence so compiling does take long take longer in the beginning obviously to learn the language but then you know the entire language so you have a fast and smooth conversation where interpreting doesn't take all that time to compile but the conversation is going to be slower because you have to interpret every word or every sentence all right so compile language they take longer to create something which is called Write time but they have an extremely fast run time where interpreted languages have a short right time um you know you can write and test your code quicker but they have a slower run time they're typically not as powerful so I know that was kind of an aside but I think it's good to know the the general difference between compile languages and interpreted languages so what I want to do now is show you the process of getting our JavaScript source code you know all of our functions and arrays and objects and variables get that to machine code which is just ones and zeros that can run on the CPU now at one point JavaScript engines were just simple interpreters basically like just this step here or these couple steps but over time they've become more intricate and they can optimize code better and they're a lot faster than they used to be and of course every JavaScript engine works in a different way this is really my understanding on the V8 engine which is the engine that I've studied the most and it depends on what time frame you're talking about as well because the V8 engine worked in a different way just a couple of years ago all right so keep that in mind but basically we have our source code that we write and then the first step is it's going to go into the parser and the parcel will check your source code which is your your JavaScript code and it will go through line by line and make sure that the syntax is correct if it comes across an error it stops running and sends out that error now if the code is valid it generates something called an apps an abstract syntax tree or AST which is a tree of nodes that represent the code and each node of the tree denotes a construct occurring in the text and you can almost think of it as like like how the JavaScript Dom is the document object model now the AST doesn't include things like parentheses curly braces quotes it just represents the code as a tree of nodes the AST is also not unique only to JavaScript it's used in many other languages as well now there's actually a website called AST explorer that allows you to input some code it can be JavaScript as well as many other languages and it will show you what the actual AST looks like so I just found this the other day and I thought it was pretty cool so let's just go ahead can I make this bigger let's let's do that so we'll say const x equals 100 and as you can see over here we now have a variable declaration it has a type the start and and then in declarations if we uncollapse this we should be able to see the value yep so in this init right here you'll see the value 100 and the identifier has a name of X so this is what it's going to look like when your code is is turned into this abstract syntax tree and then if I were to add let's say a function we'll call it add 10 and we'll pass in X and then let's just do a return and we'll just say we want to return X plus 10 and we'll close that up so now if we look over here let's just collapse the uh yeah so now you see the variable declaration underneath that we now have a function declaration and I'm not going to pretend I know exactly how to read this but you can see the identifier has a name of add 10 we have the params so the param of X and then in the body we have a return statement we have an argument a binary expression and then the left identifier is going to be the X so name X and then the right is going to be the value of 10. so just to give you an idea of you know what happens behind the scenes so now let's go back to my little diagram here and once we have that AST next we have The Interpreter whose job it is to take that AST and transform it into something called byte code which is an IR or intermediate representation so you can think of it as an abstraction of machine code or small building blocks that make up any JavaScript functionality when you compose them together again you don't have to fully understand the stuff I'm just giving you a high level overview now you may ask why doesn't The Interpreter compile directly to machine code well one reason is because machine code is unique to the architecture of your machine so machine code for Intel based processors is going to be different than machine code for arm processors and byte code or any intermediate representation is universal another reason is because we can run optimize stations on byte code now most engines use something called jit compilation or just in time compilation which will take our byte code and transform it into machine code on the Fly and a jit compiler helps optimize your code because it has access to certain Dynamic runtime information so the spider monkey engine uses a jit compiler called ion monkey and the V8 engine uses I think it's called turbofan and like I said earlier with a compile language like C your entire code is compiled before execution that's called aot or ahead of time compilation where just in time compilation refers to compilation at run time and again it allows for optimizations all right and then finally the machine code is then run by the machine's Hardware alright so I know that that's a lot to take in technically you don't need to know all this stuff up for practical web development but I think it can help to just understand what happens under the hood and some of this stuff can also be asked in interview questions for uh for Dev jobs just to see how much you know all right so I think that that's going to be the end of the series for now like I said in the last video I am open to suggestions if you think you know if you have something that you think will fit in this series I hope you guys enjoyed it and I'd really appreciate it if you could give it a like and maybe share with some other people and that's it thanks so much for watching