Today we'll look at the computer science behind it so that by the end of this video you should understand what a high-level single-threaded garbage-collected interpreted or just-in-time compiled prototype-based multi-paradigm dynamic language with a non-blocking event loop concurrency model really means. Ishida When you run a JavaScript program, whether it's a web application in the browser or something server side with nodejs, it needs to allocate memory on your RAM to store things for the runtime and for variables and objects that you reference in your code, and it also needs a thread from your CPU to actually execute the instructions in your code. However, as a JavaScript developer, you never really have to think about this stu The lowest level language is machine code, which is a numeric language that can be executed directly by the CPU but would be extremely difficult to build a website with because you would have to memorize a number for every single instruction that you want to run. If we go up one level to assembly, we get some syntactic sugar but each assembly language is specific to a particular CPU or operating system. One is known as an interpreter, while the other is known as a compiler. JavaScript is an interpreted language, which means that it requires an in the environment to read the actual source code and execute it. We can demonstrate this by simply going into the browser and running some JavaScript code from the console now notice how the interpreter works he stays with you all the time and he translates each of your instructions immediately one by one. One of the strangest things you'll learn is that javascript is built on prototypal inheritance. This course will have an entire video dedicated to this topic, but the general idea is that everything in JavaScript is an object, and each object has a link to its prototype, creating a prototype chain where objects can inherit behaviors from other objects. This can be a strange thing to get used to if you're used to class-based inheritance, but it's one of the low-level concepts that makes JavaScript a very flexible multi-paradigm language. So these JavaScript engines don't fundamentally change the way developers write code, but the JIT compiler improves performance in browsers and on node, but here's the thing: Because javascript is a single threaded language, it can only perform one computation at a time. What I want you to do right now in this browser tab is open the console with ctrl shift j and then create a while loop that never ends. You'll notice that nothing works in this browser tab now because if you try to click on something, it will never capture that event because the single thread is stuck in that while loop and can't move on to the next event. Go ahead and finish the process, refresh the tab, and then return here to read more about what happened. When you run your JavaScript code, the call stack and the heap are allocated on the system. The call stack is intended to be a high-performance continuous region of memory where your functions are executed. When you call a function, it creates a frame and a call stack, both of which include a copy of the function's local variables. When you call a function within a function, it adds another frame to the stack; however, when you return from a function, it removes that frame from the stack. I believe that the best way to understand the call stack is to go through some of your own code frame-by-frame. You can go into these sources tab in chrome dev tools and pause the execution of a script and then you can follow the call stack step by step if you look down here at the bottom you can see we're calling this function called current status when we call that function it then moves us up to the function body that first starts with a console log The only thing it's actually waiting for is the CPU to process your synchronous code, which for most things is on a microsecond scale. Now imagine the first iteration of the event loop, which will first handle all of these synchronous code in the script after it's done running the synchronous code it checks if there are any messages or callbacks in the queue ready to be executed. It will first handle the synchronous code, then it will go to the micro task queue and handle any callbacks that are ready from your promises, and finally it will finish by running the callbacks that are ready from your set timeouts or Dom API s, and that's how JavaScript works. I guess if all of this sounds overwhelming, don't worry too much because you don't really need to know any of it to start building stuff with JavaScript in the upcoming videos in Thank you for viewing, and I hope to speak with you soon.