2024-02-04T06:39:39.637Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
8fe7cd18-0860-4090-a783-09e043d5524a
be81a93fe81f930625784e3b271bd071c2e087e94a57977646d9a4538df152e1
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
Today on How They Do It.
JavaScript.
Today we'll look at the computer science behind it.
So 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.
If you're new here like and subscribe because this is part 2 of the full JavaScript course on FireShip IO.
Last week we learned that JavaScript is a programming language based on the ECMA 262 spec, but in order to really understand how it works in a system, we need to go to the very bottom of the stack.
And by that I mean the bare metal CPU and memory on a machine.
This is a real computer.
And on here you see the bits That make the computer work.
When you run a JavaScript program, whether that be a web application in the browser or something server side with Node.
Js, it needs to allocate memory on your RAM to store things is for the runtime and for variables and objects that you reference in your code.
Then it also needs a thread from your CPU to actually execute the instructions in your code.
Is.
But here's the thing.
As a JavaScript developer, you never really have to think about this stuff because it's a high level programming language.
But what do we really mean when we say high level?
We're talking about the degree of interaction or simplification that the language provides over the computer's hardware.
The lowest level language is machine code.
It's a numeric language that can be executed directly by the CPU, but it would be is extremely difficult to build a website with it, 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.
So we can move up another level to the c language, which provides a modern syntax and the ability to write cross platform programs, but the developer still has to be concerned with low level issues like memory allocation.
If we go one more step higher, we reach the level of languages like JavaScript and Python that use abstractions like garbage collectors and dynamic typing to simplify the way developers write their applications.
So now that we're at this high level, let's go ahead and unpack hack a few of the key terms related to JavaScript.
Now there are 2 fundamental ways that we can translate the code written in a programming language to something that the CPU can actually execute.
One of them is called an interpreter, and the other is called a compiler.
JavaScript is an interpreted language, which means that it needs to have an interpreter 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 console.
Now, notice how the interpreter works.
He stays with you all the time, and he translates each of your instructions immediately say 1 by 1.
Now this differs from a compiled language like Java or C, which will statically analyze all of your code in advance and then compile it down onto a binary that you can actually run on the machine.
He takes your complete list of instruction, and without further ado, translates the whole lot.
He then hands them back to you and goes away, leaving you all on your own.
JavaScript was never designed to be a compiled language, but in a few minutes, we'll see how modern JavaScript engines can use features of a compiler to squeeze out additional performance from the language.
Now another thing you might hear is that JavaScript is a dynamically typed language, which tends to be a common characteristic with high level interpreted languages.
And that just means that we don't use any explicit type definitions in vanilla JavaScript code.
We can look at this by comparing some statically typed Dart code to some dynamically typed JavaScript.
In the Dart code, you'll notice that we're annotating things like integers and strings, but the JS types are unknown or implicit.
And that's because the type is associated with a runtime value and not the actual variables or functions in your code.
Is.
Now, you might also hear that JavaScript is a multi paradigm language.
The vast majority of general purpose programming languages are multi paradigm, is allowing you to combine styles from declarative functional approaches or imperative object oriented approaches.
Now, one of the weirder things that you'll hear is that JavaScript is based on prototypal inheritance.
This course will have an entire video dedicated just to this topic, but the general idea is that everything in JavaScript is an object and each object holds a link to its prototype.
And this creates a prototype chain where objects can inherit behaviors from other objects.
This can be a weird thing to get used to if you're familiar with class based inheritance, but it's one of the low level concepts that makes JavaScript a very flexible multi paradigm language.
Now, let's take a second to recap.
We know that JavaScript is a high level interpreted dynamically type multi paradigm prototype based language, but it's also a single threaded garbage collected non blocking language with an event loop that can be just in time compiled.
The first set of definitions are mostly related to how JavaScript is laid out in ECMA 262.
But it doesn't specify how the interpreter should be implemented, how to manage memory, and it doesn't even mention the event loop in the entire 800 page document.
So that means it's up to the browser vendors to handle these implementation details.
And 2 of the most popular implementations are SpiderMonkey from Mozilla and v eight from Google.
The way they work is slightly different, but they both do a thing called just in time compilation.
In the case of v eight, it will compile all of your JavaScript down to native machine code before running it, as opposed to interpreting bytecode line by line like a normal interpreter.
To anyone out there who wants to go fast.
Anybody.
I wanna go fast.
So
so these JavaScript engines don't fundamentally change the way developers write their code, but the JIT compiler helps improve performance in browsers and on Node.
But here's the thing.
JavaScript is a single threaded language, so it can only do one computation at a time.
What I want you to do right now in this browser tab is open up the console with control shift j, and then create a while loop that never ends.
You'll notice that nothing works in this browser tab now.
If you try to click on something it will never capture that event because the single thread is stuck in that while loop and it can't move on to the next event.
Go into the Chrome task manager, and you should see that browser tab using close to 100% of CPU core's resources.
Go ahead and end the process, refresh the tab, and then meet me back here to learn more about why that happened.
When executing your JavaScript code, two regions of memory are allocated on the machine, the call stack and the heap.
The call stack is designed to be a high performance, continuous region of memory used to execute your functions.
When you call a function, it creates a frame in the call stack that contains a copy of its local variables.
If you call a function within a function, it will add another frame to the stack, but if you return from a function, it will pop that frame off the stack.
I think the best way to understand the call stack is to go through some of your own code frame by frame.
You can go into the 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.
A console log is a one and done operation, so it gets pushed onto the stack and then executed and immediately popped off the stack.
But then if we go to the next line, you can see it returns a function that also calls a function for its argument.
So the next step is to call that happy function for the argument, and you can see it gets pushed onto the call stack here.
And this happy function has its own local variable named Foo, which we can see on the local scope for this frame in the call stack.
And another nice thing is that you can see the this context for the function, which in this case is the window.
So the call stack will push as many frames as it needs and then start popping them off as they're executed on the machine.
But what happens if we have a situation where the call stack never reaches a return statement, for example, a recursive function.
In the Stack Overflow function, we're incrementing a count for every frame in the call stack.
Now eventually Chrome will throw a call stack size exceeded error, but an interesting thing to note here is that each frame in the call stack will contain a copy of the local count, which we can inspect by traversing through the call stack.
But what happens when we run into something a little more complex like an object that might be referenced by multiple function calls outside of this local context?
That's when the heap comes into play.
It's a mostly unstructured memory pool where we store things like objects or primitive values inside of closures.
In this code example, we have an object called my counter and then we're incrementing it with a function call.
From there, we'll go over to the memory tab in Chrome and take a heap snapshot, and then we can search for that variable by name and see it in the heap.
The special thing about the heap is that it's garbage collected.
That means that v 8 or the JS runtime will try to clear up free memory when it's no longer referenced in your code.
That doesn't mean you don't need to worry about memory, but it just means that you don't need to manually allocate and free up memory like you would in a c language.
So now that you know what the call stack and the heap are all about, we can introduce the event loop.
Now we already saw how a simple while loop can entirely break a single threaded language.
So that leads to the question of how do we handle any kind of long running task?
The answer is the event loop, so let's go ahead and write our own from scratch.
In the most basic sense is just a while loop that waits for messages from a queue, then processes their synchronous instructions to completion.
In the browser, you're already doing this all the time without even thinking about it.
You might set up an event listener for a button click.
When the user clicks that button, it sends a message to the queue, and then the runtime will process whatever JavaScript you defined as the callback for that event.
And that's what makes JavaScript non blocking because the only thing it ever does is listen to events and handle callbacks, so it's never actually waiting for the return value of a function.
The only thing it's actually waiting for is the CPU to process your synchronous code, and for most things that's on a scale of microseconds.
Now let's imagine the first iteration of the event loop.
It will first handle all of the 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.
We can demonstrate this behavior very simply by adding a set timeout to the top of the script for 0 seconds.
Now you might intuitively think that this timeout should be executed first because it's at the top of the file and it's a timeout for 0 seconds, but the event loop won't actually get to it till it's done running this first iteration of synchronous code.
Now what makes this so special is that you can offload long running jobs to completely separate thread pools.
In the browser, you might make an HTTP call that takes a few seconds to resolve, or a Node.
Js you might need to interact with the file system, but you can do these things without blocking the main JavaScript thread.
And that's almost everything you need to know about the Event Loop, but JavaScript had to go and make things a little more weird with the introduction of Promises and the Microtask queue.
If we go back to our script and add a Promise resolve after the setTimeout, you would think that we have 2 asynchronous operations here with 0 delay, so the setTimeout would fire first and then the Promise second.
But there's actually this thing called the Microtask queue for Promises, which has priority over the main task queue used for DOM APIs and set timeouts and things like that.
That means the handler for the Promise will be called back first in this case.
As the event loop goes through an iteration, it will first handle the synchronous code, then it's going to go to the microtask queue and handle any of the callbacks that are ready from your promises.
And lastly, it will finish up is by running the callbacks that are ready from your set timeouts or DOM APIs.
And that's how JavaScript works, I guess.
If all this sounded overwhelming to you, 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 this series we'll look at the practical applications of JavaScript as they relate to building real products.
Is, so make sure to subscribe and follow along with the source code on FireShip.
Io.
Thanks for watching and I will talk to you soon.

Speaker 0: Today on How They Do It.

Speaker 1: JavaScript. Today we'll look at the computer science behind it. So 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. If you're new here like and subscribe because this is part 2 of the full JavaScript course on FireShip IO. Last week we learned that JavaScript is a programming language based on the ECMA 262 spec, but in order to really understand how it works in a system, we need to go to the very bottom of the stack.

And by that I mean the bare metal CPU and memory on a machine.

Speaker 0: This is a real computer. And on here you see the bits That make the computer work.

Speaker 1: When you run a JavaScript program, whether that be a web application in the browser or something server side with Node. Js, it needs to allocate memory on your RAM to store things is for the runtime and for variables and objects that you reference in your code. Then it also needs a thread from your CPU to actually execute the instructions in your code. Is. But here's the thing.

As a JavaScript developer, you never really have to think about this stuff because it's a high level programming language. But what do we really mean when we say high level? We're talking about the degree of interaction or simplification that the language provides over the computer's hardware. The lowest level language is machine code. It's a numeric language that can be executed directly by the CPU, but it would be is extremely difficult to build a website with it, 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. So we can move up another level to the c language, which provides a modern syntax and the ability to write cross platform programs, but the developer still has to be concerned with low level issues like memory allocation. If we go one more step higher, we reach the level of languages like JavaScript and Python that use abstractions like garbage collectors and dynamic typing to simplify the way developers write their applications. So now that we're at this high level, let's go ahead and unpack hack a few of the key terms related to JavaScript. Now there are 2 fundamental ways that we can translate the code written in a programming language to something that the CPU can actually execute.

Speaker 2: One of them is called an interpreter, and the other is called a compiler.

Speaker 1: JavaScript is an interpreted language, which means that it needs to have an interpreter 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 console.

Speaker 2: Now, notice how the interpreter works. He stays with you all the time, and he translates each of your instructions immediately say 1 by 1.

Speaker 1: Now this differs from a compiled language like Java or C, which will statically analyze all of your code in advance and then compile it down onto a binary that you can actually run on the machine.

Speaker 2: He takes your complete list of instruction, and without further ado, translates the whole lot. He then hands them back to you and goes away, leaving you all on your own.

Speaker 1: JavaScript was never designed to be a compiled language, but in a few minutes, we'll see how modern JavaScript engines can use features of a compiler to squeeze out additional performance from the language. Now another thing you might hear is that JavaScript is a dynamically typed language, which tends to be a common characteristic with high level interpreted languages. And that just means that we don't use any explicit type definitions in vanilla JavaScript code. We can look at this by comparing some statically typed Dart code to some dynamically typed JavaScript. In the Dart code, you'll notice that we're annotating things like integers and strings, but the JS types are unknown or implicit.

And that's because the type is associated with a runtime value and not the actual variables or functions in your code. Is. Now, you might also hear that JavaScript is a multi paradigm language. The vast majority of general purpose programming languages are multi paradigm, is allowing you to combine styles from declarative functional approaches or imperative object oriented approaches. Now, one of the weirder things that you'll hear is that JavaScript is based on prototypal inheritance.

This course will have an entire video dedicated just to this topic, but the general idea is that everything in JavaScript is an object and each object holds a link to its prototype. And this creates a prototype chain where objects can inherit behaviors from other objects. This can be a weird thing to get used to if you're familiar with class based inheritance, but it's one of the low level concepts that makes JavaScript a very flexible multi paradigm language. Now, let's take a second to recap. We know that JavaScript is a high level interpreted dynamically type multi paradigm prototype based language, but it's also a single threaded garbage collected non blocking language with an event loop that can be just in time compiled.

The first set of definitions are mostly related to how JavaScript is laid out in ECMA 262. But it doesn't specify how the interpreter should be implemented, how to manage memory, and it doesn't even mention the event loop in the entire 800 page document. So that means it's up to the browser vendors to handle these implementation details. And 2 of the most popular implementations are SpiderMonkey from Mozilla and v eight from Google. The way they work is slightly different, but they both do a thing called just in time compilation.

In the case of v eight, it will compile all of your JavaScript down to native machine code before running it, as opposed to interpreting bytecode line by line like a normal interpreter.

Speaker 2: To anyone out there who wants to go fast. Anybody.

Speaker 0: I wanna go fast. So

Speaker 1: so these JavaScript engines don't fundamentally change the way developers write their code, but the JIT compiler helps improve performance in browsers and on Node. But here's the thing. JavaScript is a single threaded language, so it can only do one computation at a time. What I want you to do right now in this browser tab is open up the console with control shift j, and then create a while loop that never ends. You'll notice that nothing works in this browser tab now.

If you try to click on something it will never capture that event because the single thread is stuck in that while loop and it can't move on to the next event. Go into the Chrome task manager, and you should see that browser tab using close to 100% of CPU core's resources. Go ahead and end the process, refresh the tab, and then meet me back here to learn more about why that happened. When executing your JavaScript code, two regions of memory are allocated on the machine, the call stack and the heap. The call stack is designed to be a high performance, continuous region of memory used to execute your functions.

When you call a function, it creates a frame in the call stack that contains a copy of its local variables. If you call a function within a function, it will add another frame to the stack, but if you return from a function, it will pop that frame off the stack. I think the best way to understand the call stack is to go through some of your own code frame by frame. You can go into the 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. A console log is a one and done operation, so it gets pushed onto the stack and then executed and immediately popped off the stack. But then if we go to the next line, you can see it returns a function that also calls a function for its argument. So the next step is to call that happy function for the argument, and you can see it gets pushed onto the call stack here. And this happy function has its own local variable named Foo, which we can see on the local scope for this frame in the call stack.

And another nice thing is that you can see the this context for the function, which in this case is the window. So the call stack will push as many frames as it needs and then start popping them off as they're executed on the machine. But what happens if we have a situation where the call stack never reaches a return statement, for example, a recursive function. In the Stack Overflow function, we're incrementing a count for every frame in the call stack. Now eventually Chrome will throw a call stack size exceeded error, but an interesting thing to note here is that each frame in the call stack will contain a copy of the local count, which we can inspect by traversing through the call stack.

But what happens when we run into something a little more complex like an object that might be referenced by multiple function calls outside of this local context? That's when the heap comes into play. It's a mostly unstructured memory pool where we store things like objects or primitive values inside of closures. In this code example, we have an object called my counter and then we're incrementing it with a function call. From there, we'll go over to the memory tab in Chrome and take a heap snapshot, and then we can search for that variable by name and see it in the heap.

The special thing about the heap is that it's garbage collected. That means that v 8 or the JS runtime will try to clear up free memory when it's no longer referenced in your code. That doesn't mean you don't need to worry about memory, but it just means that you don't need to manually allocate and free up memory like you would in a c language. So now that you know what the call stack and the heap are all about, we can introduce the event loop. Now we already saw how a simple while loop can entirely break a single threaded language.

So that leads to the question of how do we handle any kind of long running task? The answer is the event loop, so let's go ahead and write our own from scratch. In the most basic sense is just a while loop that waits for messages from a queue, then processes their synchronous instructions to completion. In the browser, you're already doing this all the time without even thinking about it. You might set up an event listener for a button click.

When the user clicks that button, it sends a message to the queue, and then the runtime will process whatever JavaScript you defined as the callback for that event. And that's what makes JavaScript non blocking because the only thing it ever does is listen to events and handle callbacks, so it's never actually waiting for the return value of a function. The only thing it's actually waiting for is the CPU to process your synchronous code, and for most things that's on a scale of microseconds. Now let's imagine the first iteration of the event loop. It will first handle all of the 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. We can demonstrate this behavior very simply by adding a set timeout to the top of the script for 0 seconds. Now you might intuitively think that this timeout should be executed first because it's at the top of the file and it's a timeout for 0 seconds, but the event loop won't actually get to it till it's done running this first iteration of synchronous code. Now what makes this so special is that you can offload long running jobs to completely separate thread pools. In the browser, you might make an HTTP call that takes a few seconds to resolve, or a Node.

Js you might need to interact with the file system, but you can do these things without blocking the main JavaScript thread. And that's almost everything you need to know about the Event Loop, but JavaScript had to go and make things a little more weird with the introduction of Promises and the Microtask queue. If we go back to our script and add a Promise resolve after the setTimeout, you would think that we have 2 asynchronous operations here with 0 delay, so the setTimeout would fire first and then the Promise second. But there's actually this thing called the Microtask queue for Promises, which has priority over the main task queue used for DOM APIs and set timeouts and things like that. That means the handler for the Promise will be called back first in this case.

As the event loop goes through an iteration, it will first handle the synchronous code, then it's going to go to the microtask queue and handle any of the callbacks that are ready from your promises. And lastly, it will finish up is by running the callbacks that are ready from your set timeouts or DOM APIs. And that's how JavaScript works, I guess. If all this sounded overwhelming to you, 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 this series we'll look at the practical applications of JavaScript as they relate to building real products.

Is, so make sure to subscribe and follow along with the source code on FireShip. Io. Thanks for watching and I will talk to you soon.
Today on How They Do It. JavaScript. Today we'll look at the computer science behind it. So 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.
programming
If you're new here like and subscribe because this is part 2 of the full JavaScript course on FireShip IO. Last week we learned that JavaScript is a programming language based on the ECMA 262 spec, but in order to really understand how it works in a system, we need to go to the very bottom of the stack.
And by that I mean the bare metal CPU and memory on a machine. This is a real computer. And on here you see the bits That make the computer work. When you run a JavaScript program, whether that be a web application in the browser or something server side with Node.
computer science
Js, it needs to allocate memory on your RAM to store things is for the runtime and for variables and objects that you reference in your code. Then it also needs a thread from your CPU to actually execute the instructions in your code. Is. But here's the thing. As a JavaScript developer, you never really have to think about this stuff because it's a high level programming language.
But what do we really mean when we say high level? We're talking about the degree of interaction or simplification that the language provides over the computer's hardware. The lowest level language is machine code. It's a numeric language that can be executed directly by the CPU, but it would be is extremely difficult to build a website with it, 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. So we can move up another level to the c language, which provides a modern syntax and the ability to write cross platform programs, but the developer still has to be concerned with low level issues like memory allocation. If we go one more step higher, we reach the level of languages like JavaScript and Python that use abstractions like garbage collectors and dynamic typing to simplify the way developers write their applications.
computer science
languages
programming
software development
So now that we're at this high level, let's go ahead and unpack hack a few of the key terms related to JavaScript. Now there are 2 fundamental ways that we can translate the code written in a programming language to something that the CPU can actually execute. One of them is called an interpreter, and the other is called a compiler. JavaScript is an interpreted language, which means that it needs to have an interpreter 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 console. Now, notice how the interpreter works. He stays with you all the time, and he translates each of your instructions immediately say 1 by 1. Now this differs from a compiled language like Java or C, which will statically analyze all of your code in advance and then compile it down onto a binary that you can actually run on the machine. He takes your complete list of instruction, and without further ado, translates the whole lot.
programming
languages
software
software development
He then hands them back to you and goes away, leaving you all on your own. JavaScript was never designed to be a compiled language, but in a few minutes, we'll see how modern JavaScript engines can use features of a compiler to squeeze out additional performance from the language. Now another thing you might hear is that JavaScript is a dynamically typed language, which tends to be a common characteristic with high level interpreted languages. And that just means that we don't use any explicit type definitions in vanilla JavaScript code. We can look at this by comparing some statically typed Dart code to some dynamically typed JavaScript. In the Dart code, you'll notice that we're annotating things like integers and strings, but the JS types are unknown or implicit. And that's because the type is associated with a runtime value and not the actual variables or functions in your code.
Is. Now, you might also hear that JavaScript is a multi paradigm language. The vast majority of general purpose programming languages are multi paradigm, is allowing you to combine styles from declarative functional approaches or imperative object oriented approaches. Now, one of the weirder things that you'll hear is that JavaScript is based on prototypal inheritance.
ideologies
This course will have an entire video dedicated just to this topic, but the general idea is that everything in JavaScript is an object and each object holds a link to its prototype.
And this creates a prototype chain where objects can inherit behaviors from other objects. This can be a weird thing to get used to if you're familiar with class based inheritance, but it's one of the low level concepts that makes JavaScript a very flexible multi paradigm language. Now, let's take a second to recap.
evolution
We know that JavaScript is a high level interpreted dynamically type multi paradigm prototype based language, but it's also a single threaded garbage collected non blocking language with an event loop that can be just in time compiled. The first set of definitions are mostly related to how JavaScript is laid out in ECMA 262. But it doesn't specify how the interpreter should be implemented, how to manage memory, and it doesn't even mention the event loop in the entire 800 page document. So that means it's up to the browser vendors to handle these implementation details. And 2 of the most popular implementations are SpiderMonkey from Mozilla and v eight from Google.
The way they work is slightly different, but they both do a thing called just in time compilation. In the case of v eight, it will compile all of your JavaScript down to native machine code before running it, as opposed to interpreting bytecode line by line like a normal interpreter.
programming
To anyone out there who wants to go fast. Anybody. I wanna go fast. So so these JavaScript engines don't fundamentally change the way developers write their code, but the JIT compiler helps improve performance in browsers and on Node.
But here's the thing. JavaScript is a single threaded language, so it can only do one computation at a time. What I want you to do right now in this browser tab is open up the console with control shift j, and then create a while loop that never ends.
programming
You'll notice that nothing works in this browser tab now. If you try to click on something it will never capture that event because the single thread is stuck in that while loop and it can't move on to the next event. Go into the Chrome task manager, and you should see that browser tab using close to 100% of CPU core's resources. Go ahead and end the process, refresh the tab, and then meet me back here to learn more about why that happened.
When executing your JavaScript code, two regions of memory are allocated on the machine, the call stack and the heap. The call stack is designed to be a high performance, continuous region of memory used to execute your functions. When you call a function, it creates a frame in the call stack that contains a copy of its local variables.
programming
If you call a function within a function, it will add another frame to the stack, but if you return from a function, it will pop that frame off the stack.
I think the best way to understand the call stack is to go through some of your own code frame by frame. You can go into the 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. A console log is a one and done operation, so it gets pushed onto the stack and then executed and immediately popped off the stack. But then if we go to the next line, you can see it returns a function that also calls a function for its argument. So the next step is to call that happy function for the argument, and you can see it gets pushed onto the call stack here.
programming
And this happy function has its own local variable named Foo, which we can see on the local scope for this frame in the call stack. And another nice thing is that you can see the this context for the function, which in this case is the window. So the call stack will push as many frames as it needs and then start popping them off as they're executed on the machine.
programming
But what happens if we have a situation where the call stack never reaches a return statement, for example, a recursive function. In the Stack Overflow function, we're incrementing a count for every frame in the call stack. Now eventually Chrome will throw a call stack size exceeded error, but an interesting thing to note here is that each frame in the call stack will contain a copy of the local count, which we can inspect by traversing through the call stack. But what happens when we run into something a little more complex like an object that might be referenced by multiple function calls outside of this local context? That's when the heap comes into play. It's a mostly unstructured memory pool where we store things like objects or primitive values inside of closures. In this code example, we have an object called my counter and then we're incrementing it with a function call. From there, we'll go over to the memory tab in Chrome and take a heap snapshot, and then we can search for that variable by name and see it in the heap. The special thing about the heap is that it's garbage collected. That means that v 8 or the JS runtime will try to clear up free memory when it's no longer referenced in your code. That doesn't mean you don't need to worry about memory, but it just means that you don't need to manually allocate and free up memory like you would in a c language. So now that you know what the call stack and the heap are all about, we can introduce the event loop. Now we already saw how a simple while loop can entirely break a single threaded language. So that leads to the question of how do we handle any kind of long running task? The answer is the event loop, so let's go ahead and write our own from scratch.
In the most basic sense is just a while loop that waits for messages from a queue, then processes their synchronous instructions to completion. In the browser, you're already doing this all the time without even thinking about it. You might set up an event listener for a button click.
programming
When the user clicks that button, it sends a message to the queue, and then the runtime will process whatever JavaScript you defined as the callback for that event. And that's what makes JavaScript non blocking because the only thing it ever does is listen to events and handle callbacks, so it's never actually waiting for the return value of a function. The only thing it's actually waiting for is the CPU to process your synchronous code, and for most things that's on a scale of microseconds.
Now let's imagine the first iteration of the event loop. It will first handle all of the 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. We can demonstrate this behavior very simply by adding a set timeout to the top of the script for 0 seconds.
programming
Now you might intuitively think that this timeout should be executed first because it's at the top of the file and it's a timeout for 0 seconds, but the event loop won't actually get to it till it's done running this first iteration of synchronous code. Now what makes this so special is that you can offload long running jobs to completely separate thread pools. In the browser, you might make an HTTP call that takes a few seconds to resolve, or a Node. Js you might need to interact with the file system, but you can do these things without blocking the main JavaScript thread. And that's almost everything you need to know about the Event Loop, but JavaScript had to go and make things a little more weird with the introduction of Promises and the Microtask queue. If we go back to our script and add a Promise resolve after the setTimeout, you would think that we have 2 asynchronous operations here with 0 delay, so the setTimeout would fire first and then the Promise second. But there's actually this thing called the Microtask queue for Promises, which has priority over the main task queue used for DOM APIs and set timeouts and things like that. That means the handler for the Promise will be called back first in this case. As the event loop goes through an iteration, it will first handle the synchronous code, then it's going to go to the microtask queue and handle any of the callbacks that are ready from your promises. And lastly, it will finish up is by running the callbacks that are ready from your set timeouts or DOM APIs. And that's how JavaScript works, I guess. If all this sounded overwhelming to you, 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 this series we'll look at the practical applications of JavaScript as they relate to building real products. Is, so make sure to subscribe and follow along with the source code on FireShip. Io. Thanks for watching and I will talk to you soon.
video gaming
Today on How They Do It. JavaScript. Today we'll look at the computer science behind it. So 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. If you're new here like and subscribe because this is part 2 of the full JavaScript course on FireShip IO. Last week we learned that JavaScript is a programming language based on the ECMA 262 spec, but in order to really understand how it works in a system, we need to go to the very bottom of the stack. And by that I mean the bare metal CPU and memory on a machine. This is a real computer. And on here you see the bits That make the computer work. When you run a JavaScript program, whether that be a web application in the browser or something server side with Node. Js, it needs to allocate memory on your RAM to store things is for the runtime and for variables and objects that you reference in your code. Then it also needs a thread from your CPU to actually execute the instructions in your code. Is. But here's the thing. As a JavaScript developer, you never really have to think about this stuff because it's a high level programming language. But what do we really mean when we say high level? We're talking about the degree of interaction or simplification that the language provides over the computer's hardware. The lowest level language is machine code. It's a numeric language that can be executed directly by the CPU, but it would be is extremely difficult to build a website with it, 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. So we can move up another level to the c language, which provides a modern syntax and the ability to write cross platform programs, but the developer still has to be concerned with low level issues like memory allocation. If we go one more step higher, we reach the level of languages like JavaScript and Python that use abstractions like garbage collectors and dynamic typing to simplify the way developers write their applications. So now that we're at this high level, let's go ahead and unpack hack a few of the key terms related to JavaScript. Now there are 2 fundamental ways that we can translate the code written in a programming language to something that the CPU can actually execute. One of them is called an interpreter, and the other is called a compiler. JavaScript is an interpreted language, which means that it needs to have an interpreter 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 console. Now, notice how the interpreter works. He stays with you all the time, and he translates each of your instructions immediately say 1 by 1. Now this differs from a compiled language like Java or C, which will statically analyze all of your code in advance and then compile it down onto a binary that you can actually run on the machine. He takes your complete list of instruction, and without further ado, translates the whole lot. He then hands them back to you and goes away, leaving you all on your own. JavaScript was never designed to be a compiled language, but in a few minutes, we'll see how modern JavaScript engines can use features of a compiler to squeeze out additional performance from the language. Now another thing you might hear is that JavaScript is a dynamically typed language, which tends to be a common characteristic with high level interpreted languages. And that just means that we don't use any explicit type definitions in vanilla JavaScript code. We can look at this by comparing some statically typed Dart code to some dynamically typed JavaScript. In the Dart code, you'll notice that we're annotating things like integers and strings, but the JS types are unknown or implicit. And that's because the type is associated with a runtime value and not the actual variables or functions in your code. Is. Now, you might also hear that JavaScript is a multi paradigm language. The vast majority of general purpose programming languages are multi paradigm, is allowing you to combine styles from declarative functional approaches or imperative object oriented approaches. Now, one of the weirder things that you'll hear is that JavaScript is based on prototypal inheritance. This course will have an entire video dedicated just to this topic, but the general idea is that everything in JavaScript is an object and each object holds a link to its prototype. And this creates a prototype chain where objects can inherit behaviors from other objects. This can be a weird thing to get used to if you're familiar with class based inheritance, but it's one of the low level concepts that makes JavaScript a very flexible multi paradigm language. Now, let's take a second to recap. We know that JavaScript is a high level interpreted dynamically type multi paradigm prototype based language, but it's also a single threaded garbage collected non blocking language with an event loop that can be just in time compiled. The first set of definitions are mostly related to how JavaScript is laid out in ECMA 262. But it doesn't specify how the interpreter should be implemented, how to manage memory, and it doesn't even mention the event loop in the entire 800 page document. So that means it's up to the browser vendors to handle these implementation details. And 2 of the most popular implementations are SpiderMonkey from Mozilla and v eight from Google. The way they work is slightly different, but they both do a thing called just in time compilation. In the case of v eight, it will compile all of your JavaScript down to native machine code before running it, as opposed to interpreting bytecode line by line like a normal interpreter. To anyone out there who wants to go fast. Anybody. I wanna go fast. So so these JavaScript engines don't fundamentally change the way developers write their code, but the JIT compiler helps improve performance in browsers and on Node. But here's the thing. JavaScript is a single threaded language, so it can only do one computation at a time. What I want you to do right now in this browser tab is open up the console with control shift j, and then create a while loop that never ends. You'll notice that nothing works in this browser tab now. If you try to click on something it will never capture that event because the single thread is stuck in that while loop and it can't move on to the next event. Go into the Chrome task manager, and you should see that browser tab using close to 100% of CPU core's resources. Go ahead and end the process, refresh the tab, and then meet me back here to learn more about why that happened. When executing your JavaScript code, two regions of memory are allocated on the machine, the call stack and the heap. The call stack is designed to be a high performance, continuous region of memory used to execute your functions. When you call a function, it creates a frame in the call stack that contains a copy of its local variables. If you call a function within a function, it will add another frame to the stack, but if you return from a function, it will pop that frame off the stack. I think the best way to understand the call stack is to go through some of your own code frame by frame. You can go into the 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. A console log is a one and done operation, so it gets pushed onto the stack and then executed and immediately popped off the stack. But then if we go to the next line, you can see it returns a function that also calls a function for its argument. So the next step is to call that happy function for the argument, and you can see it gets pushed onto the call stack here. And this happy function has its own local variable named Foo, which we can see on the local scope for this frame in the call stack. And another nice thing is that you can see the this context for the function, which in this case is the window. So the call stack will push as many frames as it needs and then start popping them off as they're executed on the machine. But what happens if we have a situation where the call stack never reaches a return statement, for example, a recursive function. In the Stack Overflow function, we're incrementing a count for every frame in the call stack. Now eventually Chrome will throw a call stack size exceeded error, but an interesting thing to note here is that each frame in the call stack will contain a copy of the local count, which we can inspect by traversing through the call stack. But what happens when we run into something a little more complex like an object that might be referenced by multiple function calls outside of this local context? That's when the heap comes into play. It's a mostly unstructured memory pool where we store things like objects or primitive values inside of closures. In this code example, we have an object called my counter and then we're incrementing it with a function call. From there, we'll go over to the memory tab in Chrome and take a heap snapshot, and then we can search for that variable by name and see it in the heap. The special thing about the heap is that it's garbage collected. That means that v 8 or the JS runtime will try to clear up free memory when it's no longer referenced in your code. That doesn't mean you don't need to worry about memory, but it just means that you don't need to manually allocate and free up memory like you would in a c language. So now that you know what the call stack and the heap are all about, we can introduce the event loop. Now we already saw how a simple while loop can entirely break a single threaded language. So that leads to the question of how do we handle any kind of long running task? The answer is the event loop, so let's go ahead and write our own from scratch. In the most basic sense is just a while loop that waits for messages from a queue, then processes their synchronous instructions to completion. In the browser, you're already doing this all the time without even thinking about it. You might set up an event listener for a button click. When the user clicks that button, it sends a message to the queue, and then the runtime will process whatever JavaScript you defined as the callback for that event. And that's what makes JavaScript non blocking because the only thing it ever does is listen to events and handle callbacks, so it's never actually waiting for the return value of a function. The only thing it's actually waiting for is the CPU to process your synchronous code, and for most things that's on a scale of microseconds. Now let's imagine the first iteration of the event loop. It will first handle all of the 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. We can demonstrate this behavior very simply by adding a set timeout to the top of the script for 0 seconds. Now you might intuitively think that this timeout should be executed first because it's at the top of the file and it's a timeout for 0 seconds, but the event loop won't actually get to it till it's done running this first iteration of synchronous code. Now what makes this so special is that you can offload long running jobs to completely separate thread pools. In the browser, you might make an HTTP call that takes a few seconds to resolve, or a Node. Js you might need to interact with the file system, but you can do these things without blocking the main JavaScript thread. And that's almost everything you need to know about the Event Loop, but JavaScript had to go and make things a little more weird with the introduction of Promises and the Microtask queue. If we go back to our script and add a Promise resolve after the setTimeout, you would think that we have 2 asynchronous operations here with 0 delay, so the setTimeout would fire first and then the Promise second. But there's actually this thing called the Microtask queue for Promises, which has priority over the main task queue used for DOM APIs and set timeouts and things like that. That means the handler for the Promise will be called back first in this case. As the event loop goes through an iteration, it will first handle the synchronous code, then it's going to go to the microtask queue and handle any of the callbacks that are ready from your promises. And lastly, it will finish up is by running the callbacks that are ready from your set timeouts or DOM APIs. And that's how JavaScript works, I guess. If all this sounded overwhelming to you, 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 this series we'll look at the practical applications of JavaScript as they relate to building real products. Is, so make sure to subscribe and follow along with the source code on FireShip. Io. Thanks for watching and I will talk to you soon.
Today
today
on
on
How
how
They
they
Do
do
It.
it
JavaScript.
javascript
Today
today
we'll
we'll
look
look
at
at
the
the
computer
computer
science
science
behind
behind
it.
it
So
so
by
by
the
the
end
end
of
of
this
this
video
video
you
you
should
should
understand
understand
what
what
a
a
high
high
level
level
single
single
threaded,
threaded
garbage
garbage
collected,
collected
interpreted,
interpreted
or
or
just
just
in
in
time
time
compiled
compiled
prototype
prototype
based,
based
multi
multi
paradigm
paradigm
dynamic
dynamic
language
language
with
with
a
a
non
non
blocking
blocking
event
event
loop
loop
concurrency
concurrency
model
model
really
really
means.
means
If
if
you're
you're
new
new
here
here
like
like
and
and
subscribe
subscribe
because
because
this
this
is
is
part
part
2
2
of
of
the
the
full
full
JavaScript
javascript
course
course
on
on
FireShip
fireship
IO.
io
Last
last
week
week
we
we
learned
learned
that
that
JavaScript
javascript
is
is
a
a
programming
programming
language
language
based
based
on
on
the
the
ECMA
ecma
262
262
spec,
spec
but
but
in
in
order
order
to
to
really
really
understand
understand
how
how
it
it
works
works
in
in
a
a
system,
system
we
we
need
need
to
to
go
go
to
to
the
the
very
very
bottom
bottom
of
of
the
the
stack.
stack
And
and
by
by
that
that
I
i
mean
mean
the
the
bare
bare
metal
metal
CPU
cpu
and
and
memory
memory
on
on
a
a
machine.
machine
This
this
is
is
a
a
real
real
computer.
computer
And
and
on
on
here
here
you
you
see
see
the
the
bits
bits
That
that
make
make
the
the
computer
computer
work.
work
When
when
you
you
run
run
a
a
JavaScript
javascript
program,
program
whether
whether
that
that
be
be
a
a
web
web
application
application
in
in
the
the
browser
browser
or
or
something
something
server
server
side
side
with
with
Node.
node
Js,
js
it
it
needs
needs
to
to
allocate
allocate
memory
memory
on
on
your
your
RAM
ram
to
to
store
store
things
things
is
is
for
for
the
the
runtime
runtime
and
and
for
for
variables
variables
and
and
objects
objects
that
that
you
you
reference
reference
in
in
your
your
code.
code
Then
then
it
it
also
also
needs
needs
a
a
thread
thread
from
from
your
your
CPU
cpu
to
to
actually
actually
execute
execute
the
the
instructions
instructions
in
in
your
your
code.
code
Is.
is
But
but
here's
here's
the
the
thing.
thing
As
as
a
a
JavaScript
javascript
developer,
developer
you
you
never
never
really
really
have
have
to
to
think
think
about
about
this
this
stuff
stuff
because
because
it's
it's
a
a
high
high
level
level
programming
programming
language.
language
But
but
what
what
do
do
we
we
really
really
mean
mean
when
when
we
we
say
say
high
high
level?
level
We're
we're
talking
talking
about
about
the
the
degree
degree
of
of
interaction
interaction
or
or
simplification
simplification
that
that
the
the
language
language
provides
provides
over
over
the
the
computer's
computer's
hardware.
hardware
The
the
lowest
lowest
level
level
language
language
is
is
machine
machine
code.
code
It's
it's
a
a
numeric
numeric
language
language
that
that
can
can
be
be
executed
executed
directly
directly
by
by
the
the
CPU,
cpu
but
but
it
it
would
would
be
be
is
is
extremely
extremely
difficult
difficult
to
to
build
build
a
a
website
website
with
with
it,
it
because
because
you
you
would
would
have
have
to
to
memorize
memorize
a
a
number
number
for
for
every
every
single
single
instruction
instruction
that
that
you
you
want
want
to
to
run.
run
If
if
we
we
go
go
up
up
one
one
level
level
to
to
assembly,
assembly
we
we
get
get
some
some
syntactic
syntactic
sugar,
sugar
but
but
each
each
assembly
assembly
language
language
is
is
specific
specific
to
to
a
a
particular
particular
CPU
cpu
or
or
operating
operating
system.
system
So
so
we
we
can
can
move
move
up
up
another
another
level
level
to
to
the
the
c
c
language,
language
which
which
provides
provides
a
a
modern
modern
syntax
syntax
and
and
the
the
ability
ability
to
to
write
write
cross
cross
platform
platform
programs,
programs
but
but
the
the
developer
developer
still
still
has
has
to
to
be
be
concerned
concerned
with
with
low
low
level
level
issues
issues
like
like
memory
memory
allocation.
allocation
If
if
we
we
go
go
one
one
more
more
step
step
higher,
higher
we
we
reach
reach
the
the
level
level
of
of
languages
languages
like
like
JavaScript
javascript
and
and
Python
python
that
that
use
use
abstractions
abstractions
like
like
garbage
garbage
collectors
collectors
and
and
dynamic
dynamic
typing
typing
to
to
simplify
simplify
the
the
way
way
developers
developers
write
write
their
their
applications.
applications
So
so
now
now
that
that
we're
we're
at
at
this
this
high
high
level,
level
let's
let's
go
go
ahead
ahead
and
and
unpack
unpack
hack
hack
a
a
few
few
of
of
the
the
key
key
terms
terms
related
related
to
to
JavaScript.
javascript
Now
now
there
there
are
are
2
2
fundamental
fundamental
ways
ways
that
that
we
we
can
can
translate
translate
the
the
code
code
written
written
in
in
a
a
programming
programming
language
language
to
to
something
something
that
that
the
the
CPU
cpu
can
can
actually
actually
execute.
execute
One
one
of
of
them
them
is
is
called
called
an
an
interpreter,
interpreter
and
and
the
the
other
other
is
is
called
called
a
a
compiler.
compiler
JavaScript
javascript
is
is
an
an
interpreted
interpreted
language,
language
which
which
means
means
that
that
it
it
needs
needs
to
to
have
have
an
an
interpreter
interpreter
in
in
the
the
environment
environment
to
to
read
read
the
the
actual
actual
source
source
code
code
and
and
execute
execute
it.
it
We
we
can
can
demonstrate
demonstrate
this
this
by
by
simply
simply
going
going
into
into
the
the
browser
browser
and
and
running
running
some
some
JavaScript
javascript
code
code
from
from
console.
console
Now,
now
notice
notice
how
how
the
the
interpreter
interpreter
works.
works
He
he
stays
stays
with
with
you
you
all
all
the
the
time,
time
and
and
he
he
translates
translates
each
each
of
of
your
your
instructions
instructions
immediately
immediately
say
say
1
1
by
by
1.
1
Now
now
this
this
differs
differs
from
from
a
a
compiled
compiled
language
language
like
like
Java
java
or
or
C,
c
which
which
will
will
statically
statically
analyze
analyze
all
all
of
of
your
your
code
code
in
in
advance
advance
and
and
then
then
compile
compile
it
it
down
down
onto
onto
a
a
binary
binary
that
that
you
you
can
can
actually
actually
run
run
on
on
the
the
machine.
machine
He
he
takes
takes
your
your
complete
complete
list
list
of
of
instruction,
instruction
and
and
without
without
further
further
ado,
ado
translates
translates
the
the
whole
whole
lot.
lot
He
he
then
then
hands
hands
them
them
back
back
to
to
you
you
and
and
goes
goes
away,
away
leaving
leaving
you
you
all
all
on
on
your
your
own.
own
JavaScript
javascript
was
was
never
never
designed
designed
to
to
be
be
a
a
compiled
compiled
language,
language
but
but
in
in
a
a
few
few
minutes,
minutes
we'll
we'll
see
see
how
how
modern
modern
JavaScript
javascript
engines
engines
can
can
use
use
features
features
of
of
a
a
compiler
compiler
to
to
squeeze
squeeze
out
out
additional
additional
performance
performance
from
from
the
the
language.
language
Now
now
another
another
thing
thing
you
you
might
might
hear
hear
is
is
that
that
JavaScript
javascript
is
is
a
a
dynamically
dynamically
typed
typed
language,
language
which
which
tends
tends
to
to
be
be
a
a
common
common
characteristic
characteristic
with
with
high
high
level
level
interpreted
interpreted
languages.
languages
And
and
that
that
just
just
means
means
that
that
we
we
don't
don't
use
use
any
any
explicit
explicit
type
type
definitions
definitions
in
in
vanilla
vanilla
JavaScript
javascript
code.
code
We
we
can
can
look
look
at
at
this
this
by
by
comparing
comparing
some
some
statically
statically
typed
typed
Dart
dart
code
code
to
to
some
some
dynamically
dynamically
typed
typed
JavaScript.
javascript
In
in
the
the
Dart
dart
code,
code
you'll
you'll
notice
notice
that
that
we're
we're
annotating
annotating
things
things
like
like
integers
integers
and
and
strings,
strings
but
but
the
the
JS
js
types
types
are
are
unknown
unknown
or
or
implicit.
implicit
And
and
that's
that's
because
because
the
the
type
type
is
is
associated
associated
with
with
a
a
runtime
runtime
value
value
and
and
not
not
the
the
actual
actual
variables
variables
or
or
functions
functions
in
in
your
your
code.
code
Is.
is
Now,
now
you
you
might
might
also
also
hear
hear
that
that
JavaScript
javascript
is
is
a
a
multi
multi
paradigm
paradigm
language.
language
The
the
vast
vast
majority
majority
of
of
general
general
purpose
purpose
programming
programming
languages
languages
are
are
multi
multi
paradigm,
paradigm
is
is
allowing
allowing
you
you
to
to
combine
combine
styles
styles
from
from
declarative
declarative
functional
functional
approaches
approaches
or
or
imperative
imperative
object
object
oriented
oriented
approaches.
approaches
Now,
now
one
one
of
of
the
the
weirder
weirder
things
things
that
that
you'll
you'll
hear
hear
is
is
that
that
JavaScript
javascript
is
is
based
based
on
on
prototypal
prototypal
inheritance.
inheritance
This
this
course
course
will
will
have
have
an
an
entire
entire
video
video
dedicated
dedicated
just
just
to
to
this
this
topic,
topic
but
but
the
the
general
general
idea
idea
is
is
that
that
everything
everything
in
in
JavaScript
javascript
is
is
an
an
object
object
and
and
each
each
object
object
holds
holds
a
a
link
link
to
to
its
its
prototype.
prototype
And
and
this
this
creates
creates
a
a
prototype
prototype
chain
chain
where
where
objects
objects
can
can
inherit
inherit
behaviors
behaviors
from
from
other
other
objects.
objects
This
this
can
can
be
be
a
a
weird
weird
thing
thing
to
to
get
get
used
used
to
to
if
if
you're
you're
familiar
familiar
with
with
class
class
based
based
inheritance,
inheritance
but
but
it's
it's
one
one
of
of
the
the
low
low
level
level
concepts
concepts
that
that
makes
makes
JavaScript
javascript
a
a
very
very
flexible
flexible
multi
multi
paradigm
paradigm
language.
language
Now,
now
let's
let's
take
take
a
a
second
second
to
to
recap.
recap
We
we
know
know
that
that
JavaScript
javascript
is
is
a
a
high
high
level
level
interpreted
interpreted
dynamically
dynamically
type
type
multi
multi
paradigm
paradigm
prototype
prototype
based
based
language,
language
but
but
it's
it's
also
also
a
a
single
single
threaded
threaded
garbage
garbage
collected
collected
non
non
blocking
blocking
language
language
with
with
an
an
event
event
loop
loop
that
that
can
can
be
be
just
just
in
in
time
time
compiled.
compiled
The
the
first
first
set
set
of
of
definitions
definitions
are
are
mostly
mostly
related
related
to
to
how
how
JavaScript
javascript
is
is
laid
laid
out
out
in
in
ECMA
ecma
262.
262
But
but
it
it
doesn't
doesn't
specify
specify
how
how
the
the
interpreter
interpreter
should
should
be
be
implemented,
implemented
how
how
to
to
manage
manage
memory,
memory
and
and
it
it
doesn't
doesn't
even
even
mention
mention
the
the
event
event
loop
loop
in
in
the
the
entire
entire
800
800
page
page
document.
document
So
so
that
that
means
means
it's
it's
up
up
to
to
the
the
browser
browser
vendors
vendors
to
to
handle
handle
these
these
implementation
implementation
details.
details
And
and
2
2
of
of
the
the
most
most
popular
popular
implementations
implementations
are
are
SpiderMonkey
spidermonkey
from
from
Mozilla
mozilla
and
and
v
v
eight
eight
from
from
Google.
google
The
the
way
way
they
they
work
work
is
is
slightly
slightly
different,
different
but
but
they
they
both
both
do
do
a
a
thing
thing
called
called
just
just
in
in
time
time
compilation.
compilation
In
in
the
the
case
case
of
of
v
v
eight,
eight
it
it
will
will
compile
compile
all
all
of
of
your
your
JavaScript
javascript
down
down
to
to
native
native
machine
machine
code
code
before
before
running
running
it,
it
as
as
opposed
opposed
to
to
interpreting
interpreting
bytecode
bytecode
line
line
by
by
line
line
like
like
a
a
normal
normal
interpreter.
interpreter
To
to
anyone
anyone
out
out
there
there
who
who
wants
wants
to
to
go
go
fast.
fast
Anybody.
anybody
I
i
wanna
wanna
go
go
fast.
fast
So
so
so
so
these
these
JavaScript
javascript
engines
engines
don't
don't
fundamentally
fundamentally
change
change
the
the
way
way
developers
developers
write
write
their
their
code,
code
but
but
the
the
JIT
jit
compiler
compiler
helps
helps
improve
improve
performance
performance
in
in
browsers
browsers
and
and
on
on
Node.
node
But
but
here's
here's
the
the
thing.
thing
JavaScript
javascript
is
is
a
a
single
single
threaded
threaded
language,
language
so
so
it
it
can
can
only
only
do
do
one
one
computation
computation
at
at
a
a
time.
time
What
what
I
i
want
want
you
you
to
to
do
do
right
right
now
now
in
in
this
this
browser
browser
tab
tab
is
is
open
open
up
up
the
the
console
console
with
with
control
control
shift
shift
j,
j
and
and
then
then
create
create
a
a
while
while
loop
loop
that
that
never
never
ends.
ends
You'll
you'll
notice
notice
that
that
nothing
nothing
works
works
in
in
this
this
browser
browser
tab
tab
now.
now
If
if
you
you
try
try
to
to
click
click
on
on
something
something
it
it
will
will
never
never
capture
capture
that
that
event
event
because
because
the
the
single
single
thread
thread
is
is
stuck
stuck
in
in
that
that
while
while
loop
loop
and
and
it
it
can't
can't
move
move
on
on
to
to
the
the
next
next
event.
event
Go
go
into
into
the
the
Chrome
chrome
task
task
manager,
manager
and
and
you
you
should
should
see
see
that
that
browser
browser
tab
tab
using
using
close
close
to
to
100%
100%
of
of
CPU
cpu
core's
core's
resources.
resources
Go
go
ahead
ahead
and
and
end
end
the
the
process,
process
refresh
refresh
the
the
tab,
tab
and
and
then
then
meet
meet
me
me
back
back
here
here
to
to
learn
learn
more
more
about
about
why
why
that
that
happened.
happened
When
when
executing
executing
your
your
JavaScript
javascript
code,
code
two
two
regions
regions
of
of
memory
memory
are
are
allocated
allocated
on
on
the
the
machine,
machine
the
the
call
call
stack
stack
and
and
the
the
heap.
heap
The
the
call
call
stack
stack
is
is
designed
designed
to
to
be
be
a
a
high
high
performance,
performance
continuous
continuous
region
region
of
of
memory
memory
used
used
to
to
execute
execute
your
your
functions.
functions
When
when
you
you
call
call
a
a
function,
function
it
it
creates
creates
a
a
frame
frame
in
in
the
the
call
call
stack
stack
that
that
contains
contains
a
a
copy
copy
of
of
its
its
local
local
variables.
variables
If
if
you
you
call
call
a
a
function
function
within
within
a
a
function,
function
it
it
will
will
add
add
another
another
frame
frame
to
to
the
the
stack,
stack
but
but
if
if
you
you
return
return
from
from
a
a
function,
function
it
it
will
will
pop
pop
that
that
frame
frame
off
off
the
the
stack.
stack
I
i
think
think
the
the
best
best
way
way
to
to
understand
understand
the
the
call
call
stack
stack
is
is
to
to
go
go
through
through
some
some
of
of
your
your
own
own
code
code
frame
frame
by
by
frame.
frame
You
you
can
can
go
go
into
into
the
the
sources
sources
tab
tab
in
in
Chrome
chrome
Dev
dev
Tools
tools
and
and
pause
pause
the
the
execution
execution
of
of
a
a
script,
script
and
and
then
then
you
you
can
can
follow
follow
the
the
call
call
stack
stack
step
step
by
by
step.
step
If
if
you
you
look
look
down
down
here
here
at
at
the
the
bottom,
bottom
you
you
can
can
see
see
we're
we're
calling
calling
this
this
function
function
called
called
current
current
status.
status
When
when
we
we
call
call
that
that
function,
function
it
it
then
then
moves
moves
us
us
up
up
to
to
the
the
function
function
body
body
that
that
first
first
starts
starts
with
with
a
a
console
console
log.
log
A
a
console
console
log
log
is
is
a
a
one
one
and
and
done
done
operation,
operation
so
so
it
it
gets
gets
pushed
pushed
onto
onto
the
the
stack
stack
and
and
then
then
executed
executed
and
and
immediately
immediately
popped
popped
off
off
the
the
stack.
stack
But
but
then
then
if
if
we
we
go
go
to
to
the
the
next
next
line,
line
you
you
can
can
see
see
it
it
returns
returns
a
a
function
function
that
that
also
also
calls
calls
a
a
function
function
for
for
its
its
argument.
argument
So
so
the
the
next
next
step
step
is
is
to
to
call
call
that
that
happy
happy
function
function
for
for
the
the
argument,
argument
and
and
you
you
can
can
see
see
it
it
gets
gets
pushed
pushed
onto
onto
the
the
call
call
stack
stack
here.
here
And
and
this
this
happy
happy
function
function
has
has
its
its
own
own
local
local
variable
variable
named
named
Foo,
foo
which
which
we
we
can
can
see
see
on
on
the
the
local
local
scope
scope
for
for
this
this
frame
frame
in
in
the
the
call
call
stack.
stack
And
and
another
another
nice
nice
thing
thing
is
is
that
that
you
you
can
can
see
see
the
the
this
this
context
context
for
for
the
the
function,
function
which
which
in
in
this
this
case
case
is
is
the
the
window.
window
So
so
the
the
call
call
stack
stack
will
will
push
push
as
as
many
many
frames
frames
as
as
it
it
needs
needs
and
and
then
then
start
start
popping
popping
them
them
off
off
as
as
they're
they're
executed
executed
on
on
the
the
machine.
machine
But
but
what
what
happens
happens
if
if
we
we
have
have
a
a
situation
situation
where
where
the
the
call
call
stack
stack
never
never
reaches
reaches
a
a
return
return
statement,
statement
for
for
example,
example
a
a
recursive
recursive
function.
function
In
in
the
the
Stack
stack
Overflow
overflow
function,
function
we're
we're
incrementing
incrementing
a
a
count
count
for
for
every
every
frame
frame
in
in
the
the
call
call
stack.
stack
Now
now
eventually
eventually
Chrome
chrome
will
will
throw
throw
a
a
call
call
stack
stack
size
size
exceeded
exceeded
error,
error
but
but
an
an
interesting
interesting
thing
thing
to
to
note
note
here
here
is
is
that
that
each
each
frame
frame
in
in
the
the
call
call
stack
stack
will
will
contain
contain
a
a
copy
copy
of
of
the
the
local
local
count,
count
which
which
we
we
can
can
inspect
inspect
by
by
traversing
traversing
through
through
the
the
call
call
stack.
stack
But
but
what
what
happens
happens
when
when
we
we
run
run
into
into
something
something
a
a
little
little
more
more
complex
complex
like
like
an
an
object
object
that
that
might
might
be
be
referenced
referenced
by
by
multiple
multiple
function
function
calls
calls
outside
outside
of
of
this
this
local
local
context?
context
That's
that's
when
when
the
the
heap
heap
comes
comes
into
into
play.
play
It's
it's
a
a
mostly
mostly
unstructured
unstructured
memory
memory
pool
pool
where
where
we
we
store
store
things
things
like
like
objects
objects
or
or
primitive
primitive
values
values
inside
inside
of
of
closures.
closures
In
in
this
this
code
code
example,
example
we
we
have
have
an
an
object
object
called
called
my
my
counter
counter
and
and
then
then
we're
we're
incrementing
incrementing
it
it
with
with
a
a
function
function
call.
call
From
from
there,
there
we'll
we'll
go
go
over
over
to
to
the
the
memory
memory
tab
tab
in
in
Chrome
chrome
and
and
take
take
a
a
heap
heap
snapshot,
snapshot
and
and
then
then
we
we
can
can
search
search
for
for
that
that
variable
variable
by
by
name
name
and
and
see
see
it
it
in
in
the
the
heap.
heap
The
the
special
special
thing
thing
about
about
the
the
heap
heap
is
is
that
that
it's
it's
garbage
garbage
collected.
collected
That
that
means
means
that
that
v
v
8
8
or
or
the
the
JS
js
runtime
runtime
will
will
try
try
to
to
clear
clear
up
up
free
free
memory
memory
when
when
it's
it's
no
no
longer
longer
referenced
referenced
in
in
your
your
code.
code
That
that
doesn't
doesn't
mean
mean
you
you
don't
don't
need
need
to
to
worry
worry
about
about
memory,
memory
but
but
it
it
just
just
means
means
that
that
you
you
don't
don't
need
need
to
to
manually
manually
allocate
allocate
and
and
free
free
up
up
memory
memory
like
like
you
you
would
would
in
in
a
a
c
c
language.
language
So
so
now
now
that
that
you
you
know
know
what
what
the
the
call
call
stack
stack
and
and
the
the
heap
heap
are
are
all
all
about,
about
we
we
can
can
introduce
introduce
the
the
event
event
loop.
loop
Now
now
we
we
already
already
saw
saw
how
how
a
a
simple
simple
while
while
loop
loop
can
can
entirely
entirely
break
break
a
a
single
single
threaded
threaded
language.
language
So
so
that
that
leads
leads
to
to
the
the
question
question
of
of
how
how
do
do
we
we
handle
handle
any
any
kind
kind
of
of
long
long
running
running
task?
task
The
the
answer
answer
is
is
the
the
event
event
loop,
loop
so
so
let's
let's
go
go
ahead
ahead
and
and
write
write
our
our
own
own
from
from
scratch.
scratch
In
in
the
the
most
most
basic
basic
sense
sense
is
is
just
just
a
a
while
while
loop
loop
that
that
waits
waits
for
for
messages
messages
from
from
a
a
queue,
queue
then
then
processes
processes
their
their
synchronous
synchronous
instructions
instructions
to
to
completion.
completion
In
in
the
the
browser,
browser
you're
you're
already
already
doing
doing
this
this
all
all
the
the
time
time
without
without
even
even
thinking
thinking
about
about
it.
it
You
you
might
might
set
set
up
up
an
an
event
event
listener
listener
for
for
a
a
button
button
click.
click
When
when
the
the
user
user
clicks
clicks
that
that
button,
button
it
it
sends
sends
a
a
message
message
to
to
the
the
queue,
queue
and
and
then
then
the
the
runtime
runtime
will
will
process
process
whatever
whatever
JavaScript
javascript
you
you
defined
defined
as
as
the
the
callback
callback
for
for
that
that
event.
event
And
and
that's
that's
what
what
makes
makes
JavaScript
javascript
non
non
blocking
blocking
because
because
the
the
only
only
thing
thing
it
it
ever
ever
does
does
is
is
listen
listen
to
to
events
events
and
and
handle
handle
callbacks,
callbacks
so
so
it's
it's
never
never
actually
actually
waiting
waiting
for
for
the
the
return
return
value
value
of
of
a
a
function.
function
The
the
only
only
thing
thing
it's
it's
actually
actually
waiting
waiting
for
for
is
is
the
the
CPU
cpu
to
to
process
process
your
your
synchronous
synchronous
code,
code
and
and
for
for
most
most
things
things
that's
that's
on
on
a
a
scale
scale
of
of
microseconds.
microseconds
Now
now
let's
let's
imagine
imagine
the
the
first
first
iteration
iteration
of
of
the
the
event
event
loop.
loop
It
it
will
will
first
first
handle
handle
all
all
of
of
the
the
synchronous
synchronous
code
code
in
in
the
the
script.
script
After
after
it's
it's
done
done
running
running
the
the
synchronous
synchronous
code,
code
it
it
checks
checks
if
if
there
there
are
are
any
any
messages
messages
or
or
callbacks
callbacks
in
in
the
the
queue
queue
ready
ready
to
to
be
be
executed.
executed
We
we
can
can
demonstrate
demonstrate
this
this
behavior
behavior
very
very
simply
simply
by
by
adding
adding
a
a
set
set
timeout
timeout
to
to
the
the
top
top
of
of
the
the
script
script
for
for
0
0
seconds.
seconds
Now
now
you
you
might
might
intuitively
intuitively
think
think
that
that
this
this
timeout
timeout
should
should
be
be
executed
executed
first
first
because
because
it's
it's
at
at
the
the
top
top
of
of
the
the
file
file
and
and
it's
it's
a
a
timeout
timeout
for
for
0
0
seconds,
seconds
but
but
the
the
event
event
loop
loop
won't
won't
actually
actually
get
get
to
to
it
it
till
till
it's
it's
done
done
running
running
this
this
first
first
iteration
iteration
of
of
synchronous
synchronous
code.
code
Now
now
what
what
makes
makes
this
this
so
so
special
special
is
is
that
that
you
you
can
can
offload
offload
long
long
running
running
jobs
jobs
to
to
completely
completely
separate
separate
thread
thread
pools.
pools
In
in
the
the
browser,
browser
you
you
might
might
make
make
an
an
HTTP
http
call
call
that
that
takes
takes
a
a
few
few
seconds
seconds
to
to
resolve,
resolve
or
or
a
a
Node.
node
Js
js
you
you
might
might
need
need
to
to
interact
interact
with
with
the
the
file
file
system,
system
but
but
you
you
can
can
do
do
these
these
things
things
without
without
blocking
blocking
the
the
main
main
JavaScript
javascript
thread.
thread
And
and
that's
that's
almost
almost
everything
everything
you
you
need
need
to
to
know
know
about
about
the
the
Event
event
Loop,
loop
but
but
JavaScript
javascript
had
had
to
to
go
go
and
and
make
make
things
things
a
a
little
little
more
more
weird
weird
with
with
the
the
introduction
introduction
of
of
Promises
promises
and
and
the
the
Microtask
microtask
queue.
queue
If
if
we
we
go
go
back
back
to
to
our
our
script
script
and
and
add
add
a
a
Promise
promise
resolve
resolve
after
after
the
the
setTimeout,
settimeout
you
you
would
would
think
think
that
that
we
we
have
have
2
2
asynchronous
asynchronous
operations
operations
here
here
with
with
0
0
delay,
delay
so
so
the
the
setTimeout
settimeout
would
would
fire
fire
first
first
and
and
then
then
the
the
Promise
promise
second.
second
But
but
there's
there's
actually
actually
this
this
thing
thing
called
called
the
the
Microtask
microtask
queue
queue
for
for
Promises,
promises
which
which
has
has
priority
priority
over
over
the
the
main
main
task
task
queue
queue
used
used
for
for
DOM
dom
APIs
apis
and
and
set
set
timeouts
timeouts
and
and
things
things
like
like
that.
that
That
that
means
means
the
the
handler
handler
for
for
the
the
Promise
promise
will
will
be
be
called
called
back
back
first
first
in
in
this
this
case.
case
As
as
the
the
event
event
loop
loop
goes
goes
through
through
an
an
iteration,
iteration
it
it
will
will
first
first
handle
handle
the
the
synchronous
synchronous
code,
code
then
then
it's
it's
going
going
to
to
go
go
to
to
the
the
microtask
microtask
queue
queue
and
and
handle
handle
any
any
of
of
the
the
callbacks
callbacks
that
that
are
are
ready
ready
from
from
your
your
promises.
promises
And
and
lastly,
lastly
it
it
will
will
finish
finish
up
up
is
is
by
by
running
running
the
the
callbacks
callbacks
that
that
are
are
ready
ready
from
from
your
your
set
set
timeouts
timeouts
or
or
DOM
dom
APIs.
apis
And
and
that's
that's
how
how
JavaScript
javascript
works,
works
I
i
guess.
guess
If
if
all
all
this
this
sounded
sounded
overwhelming
overwhelming
to
to
you,
you
don't
don't
worry
worry
too
too
much
much
because
because
you
you
don't
don't
really
really
need
need
to
to
know
know
any
any
of
of
it
it
to
to
start
start
building
building
stuff
stuff
with
with
JavaScript.
javascript
In
in
the
the
upcoming
upcoming
videos
videos
in
in
this
this
series
series
we'll
we'll
look
look
at
at
the
the
practical
practical
applications
applications
of
of
JavaScript
javascript
as
as
they
they
relate
relate
to
to
building
building
real
real
products.
products
Is,
is
so
so
make
make
sure
sure
to
to
subscribe
subscribe
and
and
follow
follow
along
along
with
with
the
the
source
source
code
code
on
on
FireShip.
fireship
Io.
io
Thanks
thanks
for
for
watching
watching
and
and
I
i
will
will
talk
talk
to
to
you
you
soon.
soon
success
The high level of programming language in JavaScript is a single threaded language, which requires an interpreter and allows multiple computation at a time. The event loop is designed to be a high-performance, continuous region of memory, and the call stack can be a garbage- collector. Learning and following the source code for practical applications of JavaScript is crucial for practical applications of JavaScript.
JavaScript: How It's Made
Learn the computer science 🔬🤓 behind #JavaScript by looking at how it works under the hood. Understand why JS is called 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" https://fireship.io/courses/javascript/intro-how-js-works/

#compsci #howitsmade

- MDN Event Loop https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
- Bits and Bytes channel https://www.youtube.com/user/bitsandbytestvo
- Chrome v8 https://v8.dev/

Take the JavaScript quizzes:

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment.