Think in JavaScript – The Hard & Conceptual Parts (Full Course)

[00:00] Master the internal mechanics of [00:02] JavaScript and build an engineering [00:05] grade mental model of how the language [00:07] engine actually functions. This [00:10] comprehensive course covers advanced [00:13] conceptual topics ranging from execution [00:16] contexts and closures to the [00:19] complexities of multi-threading in [00:21] Node.js. Whether you're preparing for a [00:23] senior engineering interview or [00:26] architecting high-scale applications, [00:29] this roadmap will bridge the gap between [00:32] simply writing code and truly [00:34] engineering systems. Sumit Saha created [00:37] this course. Most developers learn [00:40] JavaScript by memorizing syntax, but the [00:42] best engineers understand the engine. [00:44] Welcome to thinking in a JavaScript way. [00:47] In this comprehensive course, we are [00:49] moving beyond the surface. We'll start [00:51] by mastering the invisible boundaries of [00:53] scope and closures before peeling back [00:56] the curtain on the execution context and [00:58] hoisting to see how the engine actually [01:01] thinks. We'll bridge the gap between [01:03] functional logic and object-oriented [01:05] programming through prototypes and [01:08] master the browser's pulse with even [01:10] delegation and propagation. Finally, [01:13] we'll scale into high-performance [01:14] territory covering asynchrony, [01:17] memoization, and the complex world of [01:19] multi-threading in both the browser and [01:22] Node.js. Whether you are a junior [01:24] developer hit by weird bugs or a senior [01:27] engineer looking to solidify your [01:29] foundation for high-level architecture, [01:32] this course was built for you. By the [01:34] end of this journey, you won't just [01:36] writing JavaScript, you'll be thinking [01:38] in it. Let's dive in. [01:48] Suppose I define a variable var x is [01:51] equal to 23. Then I print it in the [01:53] console using console.log. After saving [01:56] the file, notice that the browser [01:58] console shows 23. Perfect. Now, the [02:01] variable x I defined here is declared [02:03] openly, meaning it's not inside any [02:06] function. It's defined right at the root [02:08] of the program. [02:09] Next, let's say I create a function [02:11] named my funk. Inside that function, I [02:14] write var y = 10. [02:17] This variable y exists only within the [02:20] my funk function. It doesn't exist in [02:23] the root. [02:24] Think of it this way. The root contains [02:26] the function, and inside that function [02:29] lives the variable y. Clear? [02:31] Now, when we talk about this my funk [02:34] function, everything inside its curly [02:36] brackets belongs to the world of my [02:38] funk. Anything outside that, the root [02:41] level, is the parent's world. So, you [02:43] can imagine it like this. My funk is a [02:46] child, and the root is the parent. [02:49] We know that when we define a variable [02:51] globally in the browser, it actually [02:53] becomes a part of the window object. For [02:56] example, earlier we defined x = 23. When [02:59] we did that, it automatically got [03:01] attached to the window object. If we now [03:03] write window.x inside console.log, and [03:06] then save the file, you'll see in the [03:07] browser that it prints 23, right? That [03:10] means the variable x is actually a [03:12] property of the window object. But, the [03:14] interesting part is we don't need to [03:16] write the word window every time. The [03:18] browser automatically understands it [03:20] because it knows that x is a variable [03:22] from the global scope. Now, notice [03:24] something. So far, we have printed x [03:26] inside the parent scope. This time, [03:28] let's also print it inside our function. [03:31] So, inside my funk, let's write [03:34] console.log printing x from my funk. [03:38] Then, we call the my funk function. [03:40] After saving and running it in the [03:41] browser, you will see it prints printing [03:44] 23 from my funk. That means I can access [03:47] the parent variable from inside the [03:49] child. In other words, from inside the [03:51] function. This might sound very normal, [03:54] but in the world of web development, [03:55] it's not quite the same everywhere. [03:58] Because in web development, there are [03:59] many different programming languages. [04:01] Some developers use JavaScript, while [04:03] others use PHP, .NET, or Ruby to build [04:06] web applications. So, when developers [04:09] come to JavaScript from another [04:11] language, they often find this behavior [04:13] weird. Because in most other languages [04:16] like PHP, you can't do this. You can't [04:18] simply define a variable globally or [04:20] outside a function and then access it [04:22] freely from within a function. That's [04:24] exactly why many people think JavaScript [04:26] is a weird or even a toy language. The [04:29] truth is, JavaScript is quite liberal [04:32] when it comes to variable sharing. [04:34] Whereas, most other languages are much [04:36] stricter about it. To make this concept [04:38] easier to remember, let's think of a [04:40] simple real-life example. When we were [04:43] kids, our parents used to buy us [04:45] chocolates or toys. We would play with [04:47] them or eat them freely. No one stopped [04:50] us. In other words, whatever the parent [04:52] brought, the child could use. But when [04:55] we grew older and started buying things [04:57] with our own money, those things were [04:59] only ours. Our parents didn't use them. [05:02] The same thing happens in JavaScript. A [05:05] child can use the parent's belongings, [05:07] but the parent cannot use what belongs [05:09] to the child. Throughout this lesson, we [05:11] have been using the word world. In [05:13] JavaScript, this world is called a [05:16] scope. That means if we create a [05:18] function, the area inside its two curly [05:20] braces is the function's own world. We [05:23] call it is the function scope. And the [05:25] outermost level, the root or the parent, [05:28] is called the global scope. Some people [05:30] also call it the window scope. Clear? [05:33] That's the basic definition of scope. [05:35] Now, let's see a few implementations to [05:37] understand why scope is such an [05:39] important concept. [05:40] Earlier inside our myFunc function, we [05:42] defined Y is equal to 10, right? Now, [05:46] instead of printing X inside our console [05:48] log, let's replace X with Y. So, we will [05:51] update the code to print Y instead. [05:54] Then, outside the my func function, in [05:57] the global scope, we will again write [05:59] console.log Y to print it. [06:02] All right. Now, save the file and check [06:04] the browser console. You will notice [06:06] that Y prints once successfully, but the [06:09] second time it shows an error. [06:11] The error says reference error. [06:14] A reference error means that JavaScript [06:16] couldn't find the variable Y. [06:18] That's because we defined Y inside the [06:21] function scope. So, we can use Y inside [06:24] that function, but not outside it. Not [06:26] in the global scope. It's just like the [06:28] parent and child example, right? The [06:30] child can use what the parent gives, but [06:33] the parent can't use what belongs only [06:34] to the child. Let's look at another [06:36] example. Earlier in the parent scope, we [06:39] defined var X is equal to 10, right? [06:42] Now, inside our my func function, [06:44] instead of writing var Y is equal to 10, [06:47] let's replace that with X is equal to [06:49] 10. Also, update the console.log inside [06:52] the function. Replace Y with X. Then, [06:55] update the global console.log as well to [06:57] print X. [06:58] Now, save the file and check the browser [07:00] console. [07:01] You will notice that the value of X has [07:03] changed. That means the child scope, our [07:06] function, can also modify values that [07:08] belong to the parent scope. [07:11] Now, let's see something even more [07:12] interesting. If we add the var keyword [07:15] before X inside the my func function, so [07:18] it becomes var X is equal to 10, and [07:20] then save the file again, and look at [07:22] the browser console, here's what [07:24] happens. [07:25] Inside the my func function, the output [07:27] for X shows 10, but the global [07:30] console.log still shows 23. [07:32] What's happening here is this. If I [07:34] write X is equal to 10 without using [07:36] var, JavaScript assumes I am modifying [07:39] the global X. But if I use var X is [07:42] equal to 10 inside the function, [07:44] JavaScript treats it as a completely new [07:47] variable that exists only inside that [07:49] function's scope. However, directly [07:51] modifying a global variable from inside [07:53] a function can be very risky, especially [07:56] in large code bases. It can cause [07:58] variable name conflicts and data [08:00] mismatches that are hard to debug later. [08:02] So, this is how scopes work in [08:04] JavaScript. Now, scopes in JavaScript [08:07] are mainly of three types. The first one [08:09] is global scope. Any defined in the root [08:12] or global level can be accessed from any [08:15] inner scope, including functions. That's [08:18] what we call the global scope. [08:20] The second one is function scope. Any [08:22] variable defined inside a function can [08:24] only be used within that specific [08:26] function. If you try to access it from [08:28] outside, JavaScript will throw a [08:30] reference error. [08:32] And finally, we have block scope. Let's [08:34] see an example of that. [08:36] Inside our my func function, we will [08:38] define an if block. So, we write if [08:41] true. [08:42] Since we have given true as the [08:43] condition, that means every time my func [08:45] is called, this logic will always be [08:47] true and the program will enter the [08:48] block. [08:49] Now, inside this if block, we will write [08:52] var a is equal to five. [08:54] And on the next line, let b is equal to [08:56] 10. [08:57] So, here we have created two variables, [09:00] one with var and the other with let. [09:02] Next, outside the if block, we will try [09:05] to print both of them using console.log [09:07] a and console.log b. To make the output [09:10] clearer, we will remove all the other [09:12] console.logs from the code so that only [09:13] a and b get printed. [09:16] Now, save the file and check the browser [09:17] console. You will notice that the value [09:20] of a prints correctly, but when it comes [09:22] to b, it throws a reference error. [09:25] And the reason behind that is block [09:27] scope. Variables declared with var [09:29] belong to the function scope, meaning [09:31] they can be accessed from anywhere [09:33] inside the entire function. But, [09:35] variables declared with let or const are [09:37] limited to the block scope. That means [09:40] they can only be accessed inside the [09:42] curly braces block where they were [09:44] defined. [09:45] So, the variable var a can be accessed [09:48] throughout the entire function, while [09:51] let b is visible only inside the if [09:53] block. [09:54] If we try to access it from outside, [09:56] JavaScript throws a reference error [09:58] because once we step out of that block, [10:00] JavaScript can no longer find that [10:02] variable. That's why we say variables [10:05] declared with let or const are block [10:07] scoped, whereas variables declared with [10:10] var are function scoped. If we had [10:12] printed b inside the if block using [10:14] console.log b, it would have worked [10:16] perfectly because variables declared [10:19] with let or const are only accessible [10:21] within their block scope. I hope this [10:23] explanation helped you clearly [10:24] understand the concept of scope. To [10:26] summarize everything, scope is simply [10:28] the area where a variable can be [10:30] accessed. A child can access the [10:32] parent's variable, but a parent cannot [10:35] access the child's variable. And in the [10:37] browser, the root object of the global [10:39] scope is window, while in Node.js, it's [10:41] global. I believe after today's [10:43] discussion, you will no longer be [10:45] confused about how scope works in [10:47] JavaScript. Still, if you find anything [10:49] unclear, feel free to ask in the [10:51] comments. In the next video, we'll dive [10:53] into some more of JavaScript's weird but [10:56] beautiful concepts like closures, [10:58] hoisting, and the execution context. [11:01] Thanks for watching everyone. [11:05] Hi everyone. I hope everyone is doing [11:07] well. Today's tutorial is about a topic [11:09] in JavaScript that many developers find [11:11] a bit intimidating, closures. In my [11:14] nearly 17 years of programming [11:16] experience, I have noticed that just [11:18] hearing the word closure makes a lot of [11:21] JavaScript developers nervous, almost [11:23] instinctively. So, the main goal of this [11:25] tutorial is to remove that fear. By the [11:28] end of this video, you should be able to [11:30] confidently say, "No more fear of [11:33] closures." Closures aren't actually [11:35] complicated at all. We often make them [11:38] seem hard just because we don't [11:40] understand them clearly. Many tutorials [11:43] don't explain the topic deeply, which [11:45] leaves us confused asking questions [11:48] like, "What exactly is closure?" or [11:50] "What does it really mean?" In this [11:53] video, I will walk you through several [11:55] examples step by step, so it might be a [11:57] bit long, but if you stick with me [12:01] I promise all your confusion about [12:03] closures will disappear. Let's get [12:06] started. Usually, when we want to use an [12:08] outside variable inside a function, we [12:10] pass it as a parameter. For example, [12:13] let's say we write a function called [12:14] sum. [12:16] Here, two numbers are taken as [12:17] parameters. Now, if we want to add these [12:20] numbers and return the result, we write [12:23] return num1 + num2. [12:25] If we want to see the output, we write [12:28] console.log and pass sum (2, 3). [12:31] The output will be five. Simple, right? [12:34] But in JavaScript, there's a way to do [12:36] the same thing without passing [12:38] parameters. How? Now, let's remove the [12:41] parameters from the sum function. Then, [12:43] outside the function, in the global [12:45] scope, we define two variables, [12:47] num1 and num2. [12:50] Now, even if we call sum function, the [12:53] output will still be five. [12:56] So, the question is, how does JavaScript [12:58] do this? [12:59] It seems a bit strange, right? [13:01] Inside a function, we are using [13:03] variables that don't actually belong to [13:05] that function. They exist outside the [13:08] wider environment where the function was [13:10] created. In simple terms, the function [13:12] is using variables from its parent [13:14] scope. We did a video on scope before. [13:17] This is actually one of the most [13:19] fundamental concepts in JavaScript. [13:21] Everything from a parent is accessible [13:23] to the child. And if there were nested [13:25] functions inside this function, even the [13:28] deepest child function could access [13:29] variables like num1 and num2 from the [13:32] parent. In other words, the parent's [13:34] variables are fully accessible to the [13:36] child, but nothing from the child can be [13:38] accessed by the parent. [13:40] For example, if we define a new variable [13:42] inside the sum function, it cannot be [13:44] accessed from outside the function. We [13:46] covered this in detail in our previous [13:49] scope video. So, this is the core idea [13:51] of scope. We said that the system of [13:53] scope is theoretically called lexical [13:56] scoping. [13:57] Now, you might wonder, since today's [13:59] topic is closure, why are we discussing [14:02] scope so much? It's because closures and [14:04] scope are deeply connected. [14:07] Understanding scope is essential before [14:08] we can truly grasp closures. [14:11] Now, according to lexical scoping, a [14:13] child function can access its parent's [14:15] variables, but a parent cannot access [14:18] the child's. This isn't random. [14:21] It's a specific convention or guideline [14:23] in JavaScript. But, how does this [14:26] actually work under the hood? Imagine [14:29] we're solving a problem. That's when [14:31] closures come into play. Understanding [14:33] closures is crucial for situations like [14:36] this. [14:37] The word closure literally means a bond [14:39] or enclosure. [14:41] Think of it like keeping a variable [14:43] safely locked away, just like storing [14:45] something inside a box. [14:47] Even though the box is closed, we can [14:49] still use its contents when needed. [14:52] This is why it's called a closure. [14:55] Because we keep a function's variables [14:57] enclosed in such a way that even if the [15:00] outside world cannot access them [15:01] directly, the function itself can still [15:04] use them whenever required. [15:06] To understand closures properly, we need [15:08] to remember one more small point. [15:11] In JavaScript, whenever we write a [15:13] function, the function is actually [15:15] treated as an object. [15:17] Yes, every function in JavaScript works [15:20] as an object. Just as we can console log [15:23] an object to see it, we can also console [15:25] log a function to inspect it. [15:28] Now, let's print our sum function. For [15:31] that, we write console.dir [15:34] and pass the sum function body. [15:36] Notice that we are not calling the [15:38] function. We are just printing its body. [15:40] We use dir instead of log because [15:43] console.log only shows the function [15:45] body, while console.dir [15:48] displays the function as an object, [15:50] letting us see each of its properties [15:52] one by one. You can think of it as an [15:55] upgraded version of console.log. [15:58] Looking at the output, we will see an [16:00] object. Expanding it reveals many [16:02] properties, like name, length, [16:05] prototype, and more. [16:07] At the very bottom, there's a property [16:08] called scopes. [16:10] Inside scopes, there's a section named [16:13] global containing even more details. [16:16] Today, we will mainly focus on this [16:18] scopes property. [16:20] Now, notice something. The sum function [16:22] has its own world, right? So, why is it [16:24] still referencing the global scope? [16:27] Every function actually maintains a [16:28] connection with its parent environment. [16:31] It doesn't just live in its own world. [16:34] It keeps a link to the environment where [16:36] it was created. Simply put, it always [16:38] holds a reference to its parent. [16:41] Why does it do this? Because if anything [16:43] changes in the parent environment, like [16:45] a variable's value or the need to use it [16:48] inside the function, the function can [16:50] still access it. This whole process is [16:52] the core concept of a closure. [16:55] A function keeps track of the variables [16:57] it uses from outside its own scope by [17:00] closing over its parent and its parent's [17:03] parent. Essentially, the entire scope [17:06] chain above it, holding them as [17:09] references. That's why we said this [17:11] example is actually the simplest form of [17:14] a closure. [17:15] The sum function itself is a closure [17:17] because it has captured some variables [17:20] from its outer environment and can use [17:22] them whenever needed. [17:24] Even though we often see closures [17:26] explained with examples where a function [17:28] is inside another function, the [17:31] fundamental idea starts here. Any [17:33] function that retains access to [17:35] variables from its outer scope is, in [17:38] essence, a closure. [17:40] We can understand this even more clearly [17:43] if we tweak the previous sum function a [17:45] bit. [17:46] In the earlier example, we directly [17:47] wrote return num1 + num2, right? This [17:51] time, instead of doing that, we will [17:53] have the sum function return another [17:55] function. [17:56] Return function. [17:57] And inside this inner function, we write [18:00] return num1 + num2. [18:02] So, what does this mean? The sum [18:05] function is no longer returning a value [18:07] directly. Instead, it's returning a [18:09] function. Now, let's create another [18:12] variable called my function. var myFunc [18:15] is equal to sum. [18:17] What happens here? We call the sum [18:19] function and whatever it returned, the [18:22] inner function is now stored in my [18:24] function. [18:25] In other words, myFunc is essentially [18:28] the inner function returned by sum. [18:31] Make sense, right? [18:33] If we now print myFunc to the console, [18:35] console.dir myFunc, we will see num1 and [18:39] num2 listed as variables in the output. [18:42] What does this mean? This function is [18:44] still holding onto global environment. [18:47] Even though it's an inner function, it's [18:50] still connected to the global scope and [18:52] maintains the same global references as [18:54] before. [18:55] Now, let's do one thing. Remove the num2 [18:58] variable from the global scope and [19:00] define it inside the sum function [19:02] instead. [19:04] Now, let's look at the output again. [19:06] This time in the browser, we can clearly [19:08] see something labeled closure. [19:10] In other words, the browser is directly [19:13] showing that a closure has been created [19:15] inside this function. [19:17] In older versions of Chrome, even in the [19:19] previous example, you would have seen [19:21] closure here. But in the newer versions, [19:24] it shows as global until a function [19:27] actually closes over another function. [19:30] So, whenever a function is returned from [19:32] within another function, that's when the [19:34] browser displays closure. However, keep [19:37] in mind that theoretically, the previous [19:39] example was also a kind of closure. The [19:42] difference is just in how the browser [19:44] presents it. [19:46] When we did console.dir myFunc, we saw [19:49] that this inner function is using both [19:51] num1 and num2. Where is num1? In the [19:54] global scope. And num2? Inside the sum [19:57] function scope. So, what is this inner [19:59] function doing? It's taking a reference [20:02] to num1 from the global scope and at the [20:04] same time taking a reference to num2 [20:06] from its parent function, sum. [20:09] In other words, this inner function now [20:11] carries two worlds within it. One is the [20:14] global scope and the other is its parent [20:16] scope. This is exactly what a closure [20:19] does. It keeps all the outer scopes it [20:22] needs enclosed so it can use their [20:24] variables whenever necessary. [20:26] In the browser, we can see that inside [20:28] this closure, num2 exists while num1 [20:32] remains in the global scope. So, num1 is [20:35] no longer part of the closure. [20:37] What does this mean? The function only [20:40] carries the parts of the environment it [20:42] actually needs for its execution. Simply [20:44] put, it takes all the variables it needs [20:47] along with their references as a compact [20:50] package. Think of it like the function [20:52] holding onto references. Whenever any of [20:55] these variables are updated, the [20:56] function can see those changes because [20:59] it's still connected to the same [21:00] references. So, let's say we called [21:03] myFunc is equal to sum once. [21:07] Now, if we keep calling sum function [21:09] repeatedly, there's no problem. Each [21:11] time a new function will create its own [21:14] separate scope and keep a reference to [21:16] that scope. [21:17] In simple terms, we defined a function [21:20] and then called it elsewhere. Every time [21:22] we call that function, it can still [21:24] access the data from its previous scope. [21:27] That's because every function preserves [21:29] all the information from its parent [21:30] scope as references. This is exactly how [21:33] a function remembers its outer [21:35] variables. This is what a closure is. [21:39] So, as far as we understand, this is the [21:41] core idea of a closure. Hopefully, it's [21:44] clear to everyone now. [21:46] Now, we move to the next step. This will [21:48] be a bit more advanced. I will explain [21:51] very slowly, so it might take the video [21:53] a little longer. [21:54] Closures are really important, and my [21:56] goal is that after watching this video, [21:58] no one will be afraid of the word [22:01] closure. [22:02] Those who watch from start to finish [22:04] should have a complete understanding of [22:05] closures. [22:07] There's nothing to fear about closures. [22:09] They're actually very simple. Imagine a [22:11] function. If it wants to use a variable [22:14] or data that exists outside its own [22:16] world, it brings the parent scope of [22:18] those variables along with it. In other [22:21] words, it closes over the entire parent [22:24] scope where those variables exist. [22:27] This is the concept of a closure. [22:29] Hopefully, it's crystal clear now. [22:33] Next, we'll look at several examples one [22:35] by one to understand the concept more [22:37] deeply. We'll also go through different [22:39] use cases, so it becomes easier to [22:42] grasp. So, let's get started. [22:45] Think about other programming languages. [22:47] When you want to create a private [22:49] property, what do you usually do? In [22:51] other programming languages, we define a [22:53] property inside a class and mark it as [22:56] private, so that no one can access it [22:59] directly from outside the class. [23:01] Then, inside the class, we create one or [23:04] more public functions like getters or [23:07] setters, which allow controlled access [23:10] to or modification of that property. In [23:13] other words, you can't touch the [23:14] property directly from outside. You can [23:16] only interact with it through specific [23:19] functions defined inside the class. [23:22] In JavaScript, we can achieve the same [23:24] idea much more simply using closures [23:27] entirely in a functional style. [23:30] How? Let's see an example. Suppose we [23:32] have a simple function, function bank [23:35] account and pass initial balance. [23:38] We have named it bank account and it [23:40] takes the user's initial balance as a [23:42] parameter. [23:43] Inside it, we define a variable, var [23:46] balance is equal to initial balance. [23:49] So, the user's initial balance is stored [23:52] internally in a variable called balance. [23:55] Next, we return a function that returns [23:57] this balance variable. In other words, [23:59] the balance can only be accessed through [24:01] this return function. [24:04] Outside, in the global scope, we create [24:06] a variable, var account is equal to bank [24:09] account and pass 150s. [24:13] Here, we call the bank account function [24:15] and pass 150 as the initial balance. [24:19] What is this function actually doing? [24:21] It's returning another function. So, now [24:23] the account variable holds that return [24:26] function. [24:27] If we write in the console, console.log [24:29] and pass the account function call, the [24:32] output will be 150. [24:35] But, if we try console.log and pass [24:38] balance, it won't work because the [24:41] balance variable cannot be accessed from [24:43] outside. [24:44] What does this mean? The balance [24:46] property is protected or private. [24:49] No one from the outside can directly [24:51] touch it. To see the balance, you can [24:53] only call the return function inside the [24:55] original function. This is how we keep [24:58] balance as a private variable and [25:00] control access to it. [25:02] So, what's the role of the closure here? [25:04] It's exactly what makes this possible. [25:07] The inner function is the closure. [25:09] If we write console.dir and pass [25:12] account, we'll see that inside the [25:14] account function is the return function. [25:17] Expanding it, we'll see that the balance [25:19] variable exists inside the closure. [25:22] Exactly, right? [25:23] This means that balance wasn't created [25:26] inside the account function itself. It [25:28] was created one scope level up. Yet, we [25:31] can still access balance from the return [25:34] function. It's similar to the previous [25:36] example, but this use case is slightly [25:38] different. Here, we are showing how a [25:41] private property can be kept secure. [25:43] Even though we call the inner function [25:45] from the outside, it still had access to [25:48] balance within its scope. So, the outer [25:51] scope cannot directly access balance, [25:53] but thanks to the closure, we can [25:55] maintain a reference to it. [25:57] Even though the function is called from [25:59] outside, the closure allows us to access [26:01] the private property in a protected way. [26:04] Why protected? Because we are not [26:06] accessing it directly. We can only see [26:08] balance through the function call. [26:11] This is another powerful use case of [26:12] closures. Securing private properties so [26:15] that they cannot be directly accessed [26:17] from outside, but only through specific [26:20] functions. So, this is one of the [26:22] powerful features of closures. Now, [26:24] let's look at another aspect of [26:26] closures. Let's revisit our first [26:29] example. In that example, we used a [26:31] variable called num2 inside the inner [26:34] function. That's why the function acted [26:36] as a closure. [26:38] Now, let's keep the variable, but stop [26:41] using num2 inside the inner function. If [26:44] we check the output, we'll see that the [26:45] closure is gone. [26:47] Do you see why? It's because num2 isn't [26:50] used inside the inner function. [26:53] JavaScript smartly recognizes that this [26:55] variable isn't needed, so it's not [26:58] included in the closure. [27:00] In other words, JavaScript decides on [27:02] its own variables that won't be used [27:05] inside the function, even if they exist [27:07] in the outer scope, aren't included in [27:09] the closure. [27:10] Only the variables that the function [27:12] actually needs become part of the [27:13] closure. [27:14] For example, if we define another [27:16] variable inside the sum function, var [27:19] num is equal to six, and do nothing [27:21] else, there's still no need for a [27:23] closure. But, if we modify the inner [27:26] function to return num instead of num [27:29] one, what happens? You'll see the [27:31] closure appears again. [27:33] This time the closure contains only num. [27:36] Num two won't be there, but num one [27:38] remains because it exists in the global [27:40] scope. JavaScript preserves this scope [27:43] to maintain lexical scoping. [27:45] For instance, if we look at the global [27:47] scope, we can still see num one. [27:49] Right? That's because we used the var [27:52] keyword. If we had used let, it wouldn't [27:55] be visible. [27:56] We will discuss this issue later to [27:58] avoid confusion. The key difference we [28:00] are noticing is num one exists in the [28:03] global scope, so it remains in the [28:05] closure's environment, but if a variable [28:07] inside the inner function isn't used, [28:09] it's not included in the closure. [28:12] For example, here, if we use num one, we [28:15] are accessing the global variable. So, [28:17] what happens now? Will there be a [28:19] closure? [28:20] Look, there isn't one. Since num one [28:23] exists in the global scope, there's no [28:25] extra need. The global scope is [28:27] sufficient, and no separate closure is [28:29] required. This shows how closures [28:32] actually work. [28:33] A closure decides which variables need [28:36] to be kept inside the function, and [28:38] which don't. [28:39] JavaScript makes this decision [28:41] automatically. We just need to remember [28:43] lexical scoping, so that outer scope [28:46] variables can be accessed. [28:48] In simple terms, closures make [28:50] intelligent decisions. Variables used [28:53] inside the function are kept inside. [28:56] Variables in outer scopes that aren't [28:58] used aren't included, and global [29:00] variables are accessible directly. So, [29:03] there's no need to include them in the [29:04] closure. So, here we kept num1, and it [29:08] exists in the global scope. The function [29:10] can access it directly from there, but [29:12] if the inner function used only num, [29:15] which doesn't exist in its own scope or [29:17] globally, then a closure would have to [29:19] be created to carry that variable along. [29:22] In short, a closure doesn't wrap [29:25] everything. It doesn't include variables [29:27] that are already outside. This is an [29:30] important point. Another important point [29:32] is that global scope variables are never [29:35] included in closures. Now, let's move [29:38] on. Often, there's confusion about what [29:41] a closure appears and when it just shows [29:44] global. Even senior interviewers [29:46] sometimes hesitated to call the global [29:48] scope a closure at first glance. So, [29:51] what's the real point here? Let's break [29:53] it down. If we look at JavaScript [29:56] documentation, Mozilla maintains it. I [29:58] visited their site and checked the 2016 [30:01] documentation before the current [30:03] definition. According to that old [30:06] documentation, the definition of a [30:08] closure back in 2016 highlighted [30:11] something important. In the brackets, it [30:13] said, "Variables that are used locally, [30:16] but defined in an enclosing scope." This [30:19] means variables that are used locally [30:22] inside a function, but are actually [30:23] defined in an outer scope. [30:26] This is the key point. In our previous [30:28] examples, this is exactly what was [30:30] happening. Only variables that are [30:32] actually used inside a function are [30:34] included in the closure. Variables that [30:36] exist in an outer scope, but aren't used [30:38] inside the function, aren't part of the [30:40] closure. In simple terms, a closure is a [30:43] function that remembers its local scope [30:46] along with the necessary variables from [30:48] an outer scope. So, even if the function [30:51] is called from outside, it can still [30:53] access those variables. [30:55] Now, let's go back to our example. [30:57] Suppose we have a variable num defined [30:59] outside, but we use it locally inside [31:02] the function. That's why the browser [31:04] shows it as a closure, just like the [31:06] documentation says. [31:08] But, if we don't use the outer variable [31:10] inside the return function, [31:12] like before when we did return num1 + [31:14] num2 directly, what happens? We removed [31:17] everything else and just return num1 + [31:19] num2. [31:20] If we call the sum function directly, it [31:22] works fine. But, if we did console.dir [31:25] sum, what do we see? The word closure [31:28] doesn't appear. Why? Because num2 is [31:31] local inside the function, and there's [31:33] no need to include it in a closure. A [31:35] closure is only needed to use variables [31:38] from an outer scope. [31:40] Since this is the very first level outer [31:42] scope, meaning the global scope, and [31:44] it's not inside any function, the sum [31:46] function is already capturing it in its [31:48] own scope. So, no additional closure is [31:51] created. [31:53] Now, the question is, when does the [31:55] browser show a closure and when doesn't [31:57] it? [31:58] That's the critical point. The [32:00] explanation comes straight from the [32:02] documentation. [32:03] Variables that are used locally, but [32:05] defined in an enclosing scope. [32:08] Look, our num1 variable is defined [32:10] outside, but used locally inside. [32:13] However, num1 doesn't have any enclosing [32:16] scope. Here, an enclosing scope means a [32:19] scope that wraps around another scope. [32:22] For example, inside a set of brackets. [32:25] But, num1 is directly in the global [32:27] scope, not inside any enclosing scope. [32:30] If we want to bring this into an [32:32] enclosing scope, we need to wrap the [32:34] whole thing inside a function. [32:36] We can write an anonymous function like [32:38] this. [32:39] Then we put everything inside that [32:41] function and immediately call it. This [32:44] is known as an immediately invoked [32:46] function expression or IIFE for short. [32:50] Basically, it's a function that gets [32:52] defined and executed at the same time. [32:55] When we use an IIFE, everything gets [32:57] moved into an enclosing scope. The num1 [33:00] that was previously open in the global [33:02] scope is now inside this function. So, [33:04] it's now part of an enclosing scope. If [33:07] we check in the browser and expand it, [33:09] everything looks the same as before, but [33:11] now we see the word closure, right? [33:14] That's because we have brought the [33:15] variables into an enclosing scope. So, [33:18] the browser now shows it as a closure. [33:21] To clarify, if someone ever gets [33:23] confused or disagrees, they might say [33:26] the outer one isn't a closure. It's just [33:28] a global scope. But theoretically, we [33:31] can still consider it a closure. [33:34] Some might insist that's a closure, [33:36] while others may not agree. For those [33:38] who don't, this explanation helps. The [33:41] thing is, JavaScript always keeps the [33:44] global scope intact to maintain lexical [33:46] scoping. People who disagree with me [33:49] might say the global scope is just [33:50] preserved. That's not a closure. And [33:53] that's fair. But the concept is really [33:55] the same. If a variable from an outer [33:58] scope is used or referenced inside the [34:00] function, it behaves just like a [34:02] closure. The idea is consistent. There's [34:05] a small difference, though. The global [34:07] scope keeps all variables that exist [34:09] outside any function. That's why some [34:12] might argue it's not technically a [34:14] closure. But from a theoretical [34:16] perspective, it behaves like one with [34:19] only minor differences for global [34:21] variables. [34:23] If we hadn't done this and went back to [34:25] the previous setup, the browser would no [34:27] longer show it as a closure. Look, now [34:30] the browser doesn't show it. [34:32] And the var num1 is in the global scope, [34:34] right? So, num1 is being used here. Now, [34:38] if we add another variable below it, [34:40] like var num3 is equal to five, this [34:43] num3 isn't used by the sum function. [34:46] But, if we look in the global scope, we [34:48] can still see it. The browser shows num3 [34:51] as well. [34:52] But, as we saw earlier, a closure only [34:55] keeps what's necessary. Here, num3 [34:57] exists because it's part of the global [35:00] scope. The global object always holds [35:02] references to its own variables, which [35:05] is why num3 is feasible. This often [35:08] causes confusion. Should we call it a [35:10] closure or not? My point is, in the 2016 [35:13] documentation, the term enclosing scope [35:16] was clearly mentioned. In the current [35:18] documentation, that phrase is missing. [35:21] This means they have intentionally [35:22] avoided that confusion. The modern [35:25] definition now says, "Closure is the [35:27] combination of a function bundled [35:29] together, which is a written in a more [35:31] complex way compared to before." [35:34] In the updated definition, it says, [35:36] "Closure is the combination of a [35:38] function bundled together with [35:40] references to its surrounding state." [35:43] Here, state refers to the lexical [35:45] environment. That could be the child's [35:47] environment, the parent's environment, [35:49] or the entire scope. [35:51] Based on this definition, it means a [35:52] function keeps itself along with any [35:55] variables it needs to remember, all [35:57] bundled together. [35:58] Explaining this clearly in words can be [36:01] tricky, and I might not fully capture it [36:03] right now. But, we will see some [36:05] examples ahead, which will make each use [36:08] case clear. We will show that mistakes [36:10] can happen while we use closures, why [36:13] understanding them is important, and why [36:15] closures are asked about repeatedly in [36:17] interviews. While following this [36:19] tutorial and seeing more examples, [36:21] everything should become much clearer. [36:23] Now, let's look at another aspect. We [36:26] are going back to the previous IIFE [36:28] function. Here, we have a function [36:30] called sum that adds num1 and num2 and [36:34] returns the result. Both num1 and num2 [36:36] exist inside the IIFE function. This [36:39] means we have kept the whole set up [36:41] self-contained within a closure [36:43] function. Now, when we call the sum [36:45] function, console.log and pass the sum [36:48] call, and on the next line write [36:50] console.dir sum, [36:53] let's check the output. Initially, 2 + 3 [36:55] gives 5, which is exactly what we see. [36:58] Since num1 and num2 now exist inside the [37:00] global scope of the IIFE, we can modify [37:03] these variables if we want. num1 is [37:05] equal to 6, num2 is equal to 7. Then, if [37:09] we call again console.log sum and [37:11] console.dir sum, we'll see two different [37:14] results. The first call returns 5 [37:17] because initially 2 + 3 was calculated. [37:20] After changing num1 and num2, the next [37:24] call returns 13. [37:25] So, we can see that a closure keeps hold [37:28] of the outer variables and makes them [37:30] accessible inside the function. [37:33] Now, at that moment we check the [37:35] function using console.dir, remember? [37:38] First, we expand the dir at the bottom. [37:41] Here, we see an entry labeled as closure [37:44] and inside it we notice num1 is equal to [37:47] 6 and num2 is equal to 7. Great, because [37:50] before writing dir, we had changed the [37:52] values of num1 and num2. So, it's [37:55] showing the latest values. But, if we go [37:58] back to the previous state and expand [38:00] the first console.dir, surprisingly, it [38:03] still shows num1 is equal to 6 and num2 [38:06] is equal to 7. Both are the same. Pretty [38:09] weird, isn't it? That's because when we [38:12] did console.log, the result showed 2 + [38:15] 3, but in the very next line, the values [38:17] hadn't actually changed yet. In the a [38:21] we see that inside the closure, the [38:23] values remain six and seven. [38:25] This is exactly what we have been [38:26] emphasizing. [38:28] A closure doesn't really hold the values [38:30] themselves. It holds a reference to the [38:33] variables. So, what does this mean? It [38:36] means that there's a pointer stored to [38:38] the memory location of our variable. [38:40] Once a reference is stored, the pointer [38:43] itself stays the same, but the value can [38:46] change anytime. When we use console.dir, [38:49] the browser is showing that reference, [38:51] which is why it always displays the [38:54] latest values. [38:55] The browser works very fast, and the [38:57] reference has already been updated. [39:00] When we set num1 and num2 to six and [39:03] seven inside the closure, the reference [39:06] gets updated. We are seeing the exact [39:08] same variable, but we don't see the [39:10] intermediate values. [39:12] However, when we do console.log, the [39:15] function uses its corresponding values [39:17] correctly. That's why not every change [39:20] in the intermediate scope is clearly [39:21] visible. Because of reference updates, [39:24] we always see the latest value, not the [39:26] direct intermediate state. [39:28] So, here's an important point to [39:30] understand. A closure doesn't store the [39:33] actual values inside. It stores [39:35] references to those values. [39:38] Keeping this concept in mind is really [39:40] crucial. [39:41] Now, let's look at another aspect of [39:44] closures. [39:45] Let's go back to the previous example. [39:47] Earlier, we declared two variables in [39:50] the global scope, num1 and num2. So far, [39:53] we have been using the var keyword. So, [39:56] the output will reflect that [39:57] accordingly. Now, if we don't put [39:59] anything inside an IIFE and just stay in [40:02] the global scope, we won't see any [40:04] closure in the browser. [40:06] But, where do num1 and num2 live? [40:08] Obviously, in the global scope. That's [40:11] why we write console.dir sum. [40:14] In the browser, we can see num1 and num2 [40:16] inside the global object. Now, here's [40:19] the interesting part. What happens if we [40:21] replace these var keywords with let? [40:24] Let's check that out. [40:26] This is where the difference between var [40:28] and let comes in. Many people think [40:30] they're the same, but in JavaScript var [40:33] and let are not equal. Simply put, var [40:36] is the old JavaScript declaration and [40:38] it's function scoped. That means a [40:40] variable declared with var only lives [40:43] inside the function it's defined in. If [40:45] it's defined outside any function, it [40:47] goes to the global scope. [40:49] On the other hand, let is the new ES6 [40:52] declaration and it's block scoped. That [40:55] means a variable declared with let only [40:57] exists within the block or scope where [41:00] it was defined and cannot be accessed [41:02] from outside. [41:04] One important difference is hoisting. [41:06] Variables declared with var are hoisted, [41:09] meaning JavaScript moves the declaration [41:11] to the top, but the initialization [41:13] doesn't happen. So, if you use a var [41:16] before it's declared, you will get [41:18] undefined. With let, even though it's [41:21] hoisted, the temporal dead zone ensures [41:23] that using it before declaration throws [41:25] an error. So, let's see what happens if [41:29] we declare the variable with let. [41:31] I have already provided a detailed [41:33] tutorial on hoisting in this channel. [41:35] So, please check that out for more [41:36] information. The link to that video is [41:38] in the description. So, let's see what [41:40] happens if we declare the variable with [41:42] let. Last time, when it was just in the [41:45] global scope, we could see the variables [41:47] when we did console.dir. [41:49] Now, whenever we see a new object named [41:52] script has appeared and num one and num [41:55] two are no longer in the global scope. [41:57] Why is that? It's because of the [41:58] difference between let and var that we [42:01] talked about earlier. Let is the block [42:03] scoped while var is function scoped. If [42:06] we treat the outer context as a main [42:07] function, a variable declared with var [42:10] becomes part of the global scope. But [42:13] with let, it stays within its block [42:15] scope and doesn't directly become part [42:17] of the global object. So, let actually [42:20] lives inside a separate object called [42:22] script and not in the global scope. [42:25] Understanding this is really really [42:27] important because if you follow the [42:29] tutorial and try printing variables [42:31] while using let out of habit, the output [42:33] won't be like it is with var. This can [42:36] definitely be confusing. Simply put, let [42:39] doesn't go into the global object. It [42:41] exists inside a separate script object. [42:45] But what if we wrap the whole thing in [42:47] an enclosing function again, like before [42:49] with an IIFE, where a self-invoking [42:52] function calls itself? [42:53] Let's copy this code and paste it inside [42:56] an IIFE. When we check the output now, [42:58] everything goes back inside its closure. [43:01] Ultimately, the concept of closures [43:03] remain the same. What changes is whether [43:06] the variable goes into var or let's [43:09] scope. [43:10] Now, the situation becomes a bit [43:12] simpler. We have a function and it's in [43:14] its enclosing state. According to the [43:17] definition of a closure, the inner [43:18] function of this function is using the [43:20] outer variable name one. [43:22] So, this inner function definitely needs [43:25] a closure. That closure comes from [43:27] exactly this function. JavaScript [43:29] creates the closure and packages name [43:31] one inside it. The outer global world [43:34] always exists separately, of course. [43:37] Also, remember when using console.dir in [43:40] the browser, the output will look [43:41] different depending on whether you are [43:43] dealing with let or var. [43:45] So far, all the examples we have seen [43:47] were very simple. Now, let's look at a [43:50] practical example that will help you [43:52] understand closures better and clear up [43:54] any confusion. Let's define a function. [43:57] Function stopwatch. [43:59] We have named it stopwatch and it will [44:01] work just like a real stopwatch. Like [44:03] when we start a stopwatch, wait for a [44:05] while, and then stop it to get the lapse [44:08] time. This function will do the same. [44:10] First, we write var start time is equal [44:13] to Date.now. [44:15] This stores the current time in start [44:17] time. Then, inside the function we [44:19] define get delay is equal to function. [44:22] We create a get delay function, which [44:24] will log the elapsed time to the [44:26] console. For that, we write console.log [44:29] Date.now minus start time. [44:32] Here, the elapsed time is calculated by [44:34] subtracting start time from the current [44:36] time. [44:37] Finally, we simply return this get delay [44:39] function. The stopwatch function does [44:41] just one thing. [44:43] When you call stopwatch, it starts a [44:45] stopwatch using Date.now and returns a [44:47] get delay function. When you call that [44:49] get delay function, it shows the elapsed [44:51] time from the start time to the current [44:53] moment. So, that's the entire purpose of [44:56] the function. Now, let's call it. We [44:59] write var timer is equal to stopwatch. [45:03] Here, we have started the stopwatch. [45:05] This function executes, which means [45:07] start time is set, and the get delay [45:09] function is defined. [45:11] The stopwatch function itself isn't [45:12] called directly afterward. We simply [45:15] called it once, and the outer function [45:17] returns the get delay function. We [45:19] stored this returned function in timer. [45:21] Now, on the next line, we'll create a [45:23] fake delay. [45:25] At this point, the stopwatch is already [45:27] running because we called it, but we [45:29] haven't printed anything from get delay [45:31] yet. Before calling get delay, we create [45:34] a fake delay like this. For let I is [45:37] equal to zero, I less than [45:40] 10 crore, [45:41] I plus plus. [45:43] Here, we use a large for loop to waste [45:45] some time. We chose a big number [45:47] intentionally, so it takes a noticeable [45:49] delay. [45:50] If we want, we can also perform some [45:52] expensive operations in the loop, like [45:54] calculating a random number. [45:56] Math.random into a huge number. [46:02] This way, we create a fake delay. [46:05] Now, let's come to timer. Timer is [46:07] actually a function because it was [46:09] returned by calling stopwatch. [46:12] This returned get delay function acts as [46:14] our actual timer. [46:16] Now, let's call timer and see what [46:19] happens. The output doesn't appear [46:21] instantly. It takes a moment and then it [46:23] shows up. So, we get a delay. The [46:26] question is, how is this still working? [46:29] The stopwatch function where we [46:31] initially called it has already finished [46:33] executing. That means everything inside [46:35] that function should be gone. [46:37] So, how does timer still know the value [46:40] of start time? Especially after we added [46:42] such a long delay before calling it. [46:45] This means the timer function still [46:47] remembers its parent function, [46:48] especially the start time variable [46:50] inside stopwatch. [46:52] It holds onto that reference. How? [46:55] Because of a closure. [46:57] When get delay was created, a closure [46:59] was also created inside it that kept [47:01] track of the start time variable. So, [47:04] even after the delay and even after a [47:06] long time, it can still use that old [47:09] value. [47:10] This shows that JavaScript is really [47:12] smart. It tracks all variables, [47:14] references, and closures, and when [47:16] needed, it can use them again. [47:19] Here, we are just demonstrating how [47:21] closures work. The rest is handled [47:23] automatically by JavaScript. It knows [47:26] when something is needed and makes sure [47:28] it works. This is why this behavior is [47:31] possible, because of closures. [47:34] If we do console.dir timer like before [47:37] and check the output in the browser, you [47:38] will notice it takes some time to appear [47:40] because of the delay. But even after the [47:43] delay, it still remains start time [47:45] inside the closure. [47:47] If we try console.log start time, we [47:50] won't be able to access start time [47:52] directly. But since timer is a member [47:54] function, it can use that start time we [47:57] initialized long ago before the for [47:59] loop. It still remembers start time, no [48:02] matter how long the delay. It can keep [48:05] track. [48:06] Even if there were more lines of code or [48:08] more expensive operations during the [48:09] delay, at the end of the day, when we [48:12] call the timer, the closure ensures that [48:14] start time is correctly preserved. [48:17] This is one of the fascinating aspects [48:19] of JavaScript. It can really remember [48:22] such information, and this is one of the [48:24] biggest use cases of closures. [48:27] Because of closures, no matter how many [48:30] times we call the timer function, each [48:32] call works independently and keeps its [48:34] own start time reference. [48:36] Every time a new reference is created [48:39] and held as long as it's needed. [48:42] This is a small example, but in a large [48:45] application, there could be countless [48:47] closures holding references to many [48:49] variables. Naturally, the question [48:52] arises, if so many things are being [48:54] remembered, will performance suffer? [48:57] This is where JavaScript's performance [48:59] optimization comes in. [49:01] JavaScript is a smart garbage-collected [49:03] language. That means when JavaScript [49:06] realizes that a reference or variable is [49:08] no longer needed, it automatically [49:10] removes it from memory. In some [49:12] situations, programmers can manually [49:14] optimize. For example, in our case, we [49:16] created a timer holding a reference to [49:19] the get delay function, but we haven't [49:21] called get delay yet. JavaScript doesn't [49:24] know if it will be used in the future, [49:26] so it keeps the reference. If we are [49:28] certain it won't be used anymore, we can [49:31] manually clear the reference by writing [49:33] timer is equal to null. Now, timer won't [49:36] work because we set it to null. [49:39] JavaScript understands that it's no [49:41] longer needed and garbage collects the [49:43] reference from memory. [49:45] If you try this in the browser, you'll [49:46] see an error, type error, timer is not a [49:50] function, because timer is now null. [49:53] Simply put, setting timer is equal to [49:55] null tells JavaScript this variable [49:57] won't be used anymore. Forget it. [50:00] The garbage collector then recognizes [50:01] there are no references and quietly [50:04] removes it from memory, preventing [50:06] memory wastage. The interesting part is [50:08] that JavaScript doesn't just run the [50:10] code. It predicts a lot even before [50:13] compilation. When it sees timer is equal [50:15] to null, it already knows, "Okay, the [50:18] programmer used this timer only this [50:20] much and it won't be needed anymore." [50:22] So, as soon as the code finishes [50:24] running, it intelligently cleans up the [50:26] memory. [50:28] This makes our program automatically [50:29] optimized. There are no memory leaks or [50:32] browser load decreases and JavaScript [50:34] executes faster. [50:36] This is a very small example, but it [50:38] already shows how elegantly you can [50:40] manage performance in JavaScript. So [50:42] far, all the examples we have seen were [50:45] using closures in a synchronous way. [50:47] Now, many people might wonder, "Okay, [50:50] but how do closures work in asynchronous [50:52] situations?" That's a very good [50:54] question. In real-world coding, most [50:56] tasks run asynchronously, like with set [50:59] timeout, fetch, or event listener [51:01] functions. The key point is synchronous [51:04] code executes line by line, but [51:06] asynchronous code takes some time to [51:08] complete. That means you call a [51:11] function, but its result arrives a [51:13] little later. So, the question is, "If [51:16] the outer scope has already finished by [51:18] then, how does the inner function still [51:20] remember the values of the outer [51:22] variables?" This is exactly where the [51:24] true power of closures come in. A [51:27] closure keeps the references to the [51:29] outer scope as long as the inner [51:31] function hasn't executed yet. That means [51:33] whether the code is synchronous or [51:35] asynchronous, closures work the same [51:38] way. [51:39] Now, let's see a small asynchronous [51:41] example to understand how closures work [51:43] and why they are just as is in [51:45] asynchronous scenarios. [51:47] We define a function, function async [51:50] example. [51:51] Inside this function, we write var a is [51:54] equal to 20. [51:55] We have defined a variable. Next, we [51:57] will use JavaScript's built-in set [51:59] timeout function. For that, we write set [52:02] timeout and pass a function. [52:05] We all know that set timeout takes two [52:07] parameters. One is the function to run, [52:09] and the other is the time in [52:11] milliseconds, meaning it will call that [52:13] function after the specified delay. [52:15] Now, suppose we put console.log a inside [52:19] that function. [52:20] Surprisingly, even though a isn't [52:22] defined inside the timeout function, it [52:24] can still access the a from async [52:27] example's outer scope. This is possible [52:30] because of closures. We did exactly the [52:32] same, and then finally called the async [52:35] example function. [52:36] Now, let's check the output. [52:38] After 3 seconds, it appears, and we see [52:41] 20. This is also possible because of [52:44] closures. [52:45] The function inside set timeout doesn't [52:48] have a defined within itself. Yet, it [52:51] can access a from async example's scope. [52:55] Now, what if we define the set timeout [52:57] function outside async example just for [53:00] demonstration, like this. [53:02] Function my func. [53:04] Inside my func, we write console.log a. [53:08] Then, we pass my func into set timeout [53:10] and also write console.dir my func. [53:13] If we check the output of console.dir, [53:16] we will see that inside my func, the [53:18] closure contains the variable a is equal [53:20] to 20. [53:21] This is because a was part of async [53:23] example's scope. So, my func can still [53:27] access it. [53:28] Just like before, this is possible [53:30] thanks to closures. But here, there's a [53:32] subtle difference. Earlier, we talked [53:35] about a reference example, but this [53:37] reference works a little differently. [53:40] Suppose the variable a is equal to 20 [53:43] was originally inside async example. [53:46] Now, if we move A to the global scope [53:49] and write var A is equal to 20, in [53:51] simple terms, we have defined it [53:53] outside. Now, the closure won't show it [53:56] because it's part of the global scope. [53:59] A will just exist in the global scope [54:01] with a value of 20. [54:03] We call the async example function, [54:05] which starts the set timeout timer. [54:08] Then, on the next line, after calling [54:10] async example, we change the value of A. [54:13] A is equal to 30. [54:15] Now, think. If myFunc is called as the [54:18] callback for set timeout and does [54:20] console.log A, what value will it show? [54:24] If you check the output, it will show [54:26] 30. [54:27] What does this mean? When async example [54:30] is called, the set timeout starts and [54:32] myFunc is ready as the callback. Inside [54:35] myFunc, we have console.log A. [54:38] At that moment, A was 20 in its parent [54:41] scope, but since A is now global and its [54:44] value has been changed from outside, [54:46] when the callback executes, it shows 30. [54:49] This demonstrates that closures actually [54:52] hold a reference to the variable. If the [54:54] variable is global, any external changes [54:56] are also tracked. [54:58] So, if we expand the global A in the [55:00] console, we'll see A is equal to 30. [55:04] I mentioned earlier that closures keep a [55:06] reference to the value. So, when set [55:08] timeout sends the callback to the main [55:10] thread after 3 seconds, myFunc can still [55:13] access that reference. [55:15] Remember, myFunc comes back via set [55:17] timeout from another place. It doesn't [55:20] run directly on the main thread. [55:22] This is part of asynchronous JavaScript. [55:25] The function is called in the main [55:27] thread after returning from the web API, [55:29] but it still retains the reference to A. [55:33] Since A has been changed globally, when [55:35] myFunc prints it, it shows the new value [55:37] 30. [55:39] This point is very important. Practicing [55:41] multiple examples will help you better [55:43] understand how closures track outer [55:45] variables in asynchronous situations. [55:48] This is why you need to be careful when [55:50] using global variables and var. [55:53] This is also the reason var can [55:54] sometimes cause conflicts and why the [55:57] let keyword was introduced. For example, [56:00] if we define var a globally and later [56:03] change a somewhere in the program, any [56:05] asynchronous functions referencing a [56:07] will use the new value. That's why using [56:10] var with setTimeout or other [56:12] asynchronous functions can lead to such [56:14] issues. An important point is that a [56:17] closure doesn't keep the entire variable [56:19] from its parent scope. It only keeps a [56:21] reference to that variable. Now, let's [56:24] see another practical example of [56:26] closures. In typical JavaScript [56:28] applications, we often make Ajax [56:31] requests to fetch data from an API URL. [56:34] We'll see how closures are used in this [56:36] context. We know that for API requests [56:39] like this, JavaScript's built-in fetch [56:41] function can be used. Though, [56:43] third-party libraries like Axios or [56:46] jQuery Ajax can also accomplish the same [56:48] task. [56:50] We will use fetch for a practical [56:51] example. First, we write a function [56:54] function API function and pass the URL. [56:57] We named it API function and gave it a [56:59] parameter called URL. This function will [57:01] send a request to that URL. So, what [57:04] does fetch do with the URL? Basically, [57:06] fetch returns a promise. We know that to [57:08] get the output from a promise, we use [57:11] then. So, we write {dot} then [57:14] res and return something. After the [57:17] response comes back, we use a callback [57:19] function. Here, we log the response to [57:21] the console. console.log and pass the [57:23] res variable. This is how our API [57:26] function is set up. Now, we will call [57:28] the function. We We to pass a URL for [57:31] the API call. A popular choice is JSON [57:33] placeholder. So, we use it {slash} to-do [57:36] {slash} one endpoint. We write API [57:39] function and pass the full URL. [57:41] Let's check the output. Notice that it [57:43] appears after a short delay. This is [57:46] asynchronous. To make this clearer, we [57:48] write another line below. console.log I [57:51] am here. Now, the question is which [57:53] prints first? Without a doubt, I am here [57:56] prints first and then the output from [57:58] API function appears. [58:00] This clearly demonstrates the flow of [58:02] asynchronous operations. Since the [58:04] response comes quickly, it might not [58:05] have been obvious without this extra [58:07] line. What does this mean? The output is [58:10] coming, right? Here, the connection to [58:12] closures is that we pass the URL [58:15] parameter from outside when calling API [58:17] function. This URL now exists inside the [58:20] body of API function. Fetch takes it as [58:23] a parameter and then the callback [58:24] function inside then executes much [58:27] later. [58:28] By the time the call to API function has [58:30] already finished, but the callback still [58:32] remembers the variables from its scope. [58:35] That's why even after the result [58:37] arrives, we can still access URL. To see [58:39] this, we can print it. console.log URL. [58:43] Notice that the output is correct. This [58:45] means that if there were more nested [58:47] functions inside then, like another then [58:50] inside a then, all the way down, the [58:52] innermost function could still access [58:54] the original URL. And this is possible [58:57] only because of closures. [58:59] To demonstrate, we can rewrite the [59:01] callback function inside API function a [59:03] little differently. [59:04] function handle response [59:07] This function simply does console.log [59:09] URL. Now, we pass handle response into [59:12] then. [59:13] Then, we write console.dir handle [59:16] response. [59:17] In the output, we'll see that inside [59:19] handle response, the closure contains [59:21] URL. This is because it was part of API [59:24] function's scope, so it can access it. [59:27] Hopefully, this makes it clear. [59:29] Finally, let's look at another example [59:31] that often comes up in job interviews. [59:34] This one is a bit more complex and [59:36] tricky, and it shows how using closures [59:38] inside loops can create unpredictable [59:41] output. Suppose we write a simple for [59:44] loop. For let I is equal to zero, I less [59:47] than three, I plus plus. This loop will [59:50] run three times, and inside it we define [59:52] another function, function A. [59:55] Inside this function, we simply do [59:56] console.log I. [59:58] From this, we see that the function A [60:00] exists within the scope of the for loop, [60:03] but in reality, it's also accessible in [60:05] the global scope. Then, we call the [60:07] function A. [60:09] The expected output would be 0 1 2. [60:12] First, the value of I prints zero, then [60:15] one, then two, one after another. Now, [60:18] looking at the output, we see 0 1 2. [60:21] This is because we defined I using let. [60:24] If we remove let and use var instead, [60:27] what happens? Even with var, the output [60:30] will be the same in this simple case, [60:32] because var works outside the block [60:34] scope. That is, writing for var I is [60:37] equal to zero, or declaring var I [60:40] separately behaves effectively the same. [60:42] So, in this case, there's no problem. A [60:45] closure isn't required because we are [60:47] running the function in the global [60:48] scope. Our I prints zero, then one, then [60:52] two. Everything works correctly. Now, [60:55] let's go back and use let for I again. [60:58] Suppose we want to call the A function [61:00] from outside the loop. Imagine we wrap [61:03] the whole thing in a set timeout, and [61:05] the first parameter, we pass the body of [61:08] A as a callback, while the second [61:11] parameter is 1,000 into I milliseconds. [61:15] Using this 1,000 into I, we want zero to [61:19] print after 1 second, one after 2 [61:22] seconds, and 2 after 3 seconds. When we [61:25] run this, the output comes exactly as [61:27] expected. After 1 second, 0 prints. [61:31] After 2 seconds, 1 prints. And after 3 [61:33] seconds, 2 prints. But here's the [61:35] important point. The for loop itself is [61:38] synchronous, while the functions inside [61:41] set timeout are asynchronous. That means [61:44] the functions inside set timeout will [61:46] execute one by one according to the [61:48] timer. Only after the loop has finished. [61:52] First, after 1 second, then after 2, and [61:54] then after 3. [61:56] We can verify this asynchronous [61:57] behavior. Suppose at the end of the [61:59] loop, we write console.log after for [62:03] loop. [62:04] Now, if we check the output, after for [62:06] loop prints first. Then after 1 second, [62:09] 0 prints. After 2 seconds, 1 prints. And [62:12] finally, 2 prints. [62:14] This clearly shows how asynchronous [62:16] functions execute, right? [62:19] No confusion there. [62:20] The interesting part is if we use var I [62:23] instead of let I, the behavior changes. [62:26] All three outputs end up being three. We [62:29] don't get 0, 1, 2 like before. That's [62:32] exactly the tricky part of this [62:34] question. [62:35] This question often comes up in job [62:37] interviews because it's a bit advanced. [62:39] But if you understand closures and the [62:41] difference between let and var scopes, [62:43] it's not complicated at all. [62:45] Let's analyze this by going back to the [62:48] let. So, remove var I and write let I is [62:52] equal to 0. [62:53] Now, the expected output is 0, 1, 2. [62:57] Let is block scope, meaning this I [62:59] exists only inside the loop and has no [63:01] effect outside. During the first [63:03] iteration, I is 0 and the set timeout [63:05] function is defined. This function will [63:08] be called after the loop finishes. So, a [63:10] closure is used to remember the value of [63:12] I. The callback needs a closure to [63:14] reference I correctly. Since let doesn't [63:18] leak outside the loop, each iteration [63:20] creates a new I. For example, when I [63:23] becomes one, it's a completely separate [63:25] I from the previous iteration. So, when [63:28] this function runs the second time, it [63:30] references this new I. But with var, the [63:33] situation is different. Var is function [63:35] scoped, so the same variable exists [63:38] outside the loop. If we write var I and [63:41] then use the loop, there is only one I. [63:43] Changing I inside the loop modifies the [63:46] same I. [63:47] No new I is created. So, when the set [63:51] timeout callbacks execute, they all [63:53] reference that same I. [63:55] From previous examples, we know set [63:58] timeout callbacks run after the loop [64:00] finishes. Now, after the loop ends, [64:03] what's the value of I? Since we used [64:05] var, I has become three. [64:08] Check it with console.log I. [64:10] In the console, you will see three [64:12] prints first. That means when the [64:14] callbacks execute, they all reference [64:16] the same I, which is already three. So, [64:19] every console.log in the callbacks print [64:22] I is equal to three, which explains the [64:24] output perfectly. [64:26] To understand this even better, we can [64:27] use console.dir like before. [64:30] Let's see how. First, we'll stick with [64:32] the let case. So, in the for loop, we [64:35] write let I is equal to zero. We comment [64:38] out the global var I since let is block [64:41] scoped. Now, let's see how the closure [64:43] works. The closure is created inside the [64:46] set timeout callback function, and we [64:47] want to inspect this callback function. [64:50] For that, we define function my func and [64:53] pass this my func inside set timeout. [64:56] Then, to inspect it, we write [64:58] console.dir my func. [65:00] If we run this, the browser shows the [65:02] same output. That means the dir of my [65:04] function appears three times, but in [65:06] Chrome's console, it only prints once. [65:09] Chrome wraps similar objects together. [65:11] So, even though the internal properties [65:14] are different, it doesn't display them [65:15] separately. To see each property [65:17] individually, we take the next step. [65:20] Below the DIR, we write console.log [65:23] triple hyphen. [65:24] This acts as a separator. Now, when the [65:27] browser prints my funcs DIR, it also [65:30] prints the separator, making it clear [65:32] that each instance is separate. [65:35] At the same time, outside the for loop, [65:37] we add console.log after for loop. [65:40] Now, if we check the output, the browser [65:42] prints after for loop first, then 0 1 2. [65:47] In my execution, when we defined it, the [65:49] console logs show my func and the [65:52] dashes. Notice when I is 0, the closure [65:55] holds I is equal to 0. When I is equal [65:57] to 1, the closure holds I is equal to 1. [66:00] When I is equal to 2, the closure holds [66:02] I is equal to 2. So, all three values [66:05] exist as references until the end, which [66:07] is why we get three separate outputs. [66:10] But, what happens if we replace let I [66:12] with var I? [66:14] After printing after for loop, all three [66:17] outputs show three. How? [66:19] When I is 0, there's no closure because [66:22] var moves this variable to the global [66:24] scope. Unlike the previous example, no [66:27] closure is needed here. Var exists in [66:30] the global scope, and I changes within [66:33] that same global variable. So, if we [66:36] expand the first my func in the console [66:38] and look for I in the global scope, you [66:40] will see I is equal to three. [66:42] Why? Because the for loop finishes [66:44] first, and at the end, I becomes three. [66:48] At the moment of after for loop, I is [66:50] three. This means when the reference [66:52] values are called, they still use the [66:54] reference to that I. [66:56] Even if I changes later in the program, [66:59] since the calls happen afterward, the [67:01] reference values get the updated I. [67:03] That's why the first call shows three, [67:06] the second call shows three, and the [67:08] third call also shows three. If you [67:10] expand them all, you will see I is equal [67:13] to three everywhere. This happens [67:15] because no closure is used here. It's [67:17] referencing the original I in the global [67:20] scope, which keeps updating. [67:22] The difference in scope between let and [67:24] var is why the output changes [67:26] completely. Hopefully, this is clear [67:28] now. To fix this var issue, now we can [67:30] create an IIFE inside the for loop. This [67:33] IIFE will take one parameter. In this [67:35] case, the value of our loop variable I. [67:37] All right. Let's write the code. Inside [67:40] the IIFE, we are passing a parameter [67:42] named I. Of course, you can name it [67:44] anything you want. You already know [67:46] that. But for now, we'll just keep it as [67:48] I. Then, we call the IIFE. We'll pass [67:51] the loop's I value into it. [67:54] Nice, right? Let's see what the output [67:56] looks like. This time, we get zero, one, [67:59] and two correctly. So, why is it fixed [68:01] now? Because I is now inside its own [68:04] scope within the IIFE. Whenever we pass [68:06] I to myFunc, a separate copy of that I [68:10] is created as a parameter inside myFunc, [68:13] and that copy is what gets used inside [68:15] the function. Everything is clear now. [68:17] If we expand the DIRS at the end, you [68:20] will see the last one has I is equal to [68:22] two in its closure. The second one has I [68:25] is equal to one, and the first one has I [68:28] is equal to zero. [68:29] Perfectly clear, isn't it? So, if [68:32] everything is clear, I would say if you [68:34] practice all these examples repeatedly, [68:37] your understanding of closures will [68:39] become much stronger. Of course, there [68:42] are more complex examples of closures, [68:44] but the basics we have covered today are [68:46] the most important. [68:48] Once you understand them step by step, [68:50] you will be able to create many use [68:51] cases yourself, and debugging will no [68:53] longer be difficult. Because now, with [68:55] just a glimpse at console.dir or by [68:58] playing with the code a bit, you can see [69:00] how closures actually work. In summary, [69:03] not understanding closures can make you [69:04] get stuck in many parts of JavaScript, [69:07] specially when working with asynchronous [69:08] code. That's why I explained this topic [69:11] in such detail today, went through so [69:13] many examples, so that everything [69:15] becomes clear in one go. [69:17] Now, if you are asked in a job [69:19] interview, what is a closure? You can [69:21] answer simply, a closure is a mechanism [69:24] where a function remembers variables [69:26] outside its own scope and can access [69:28] them whenever needed. In other words, [69:31] values that aren't inside the function [69:33] itself, but the function takes a [69:35] reference from its parent or outer [69:37] scope. This is what we call a closure. [69:40] So, closure is equal to function plus [69:43] remembered values. This is why closures [69:46] are so important in job interviews. They [69:48] show how deeply a programmer understands [69:51] JavaScript. If I want to recruit a [69:53] JavaScript developer, a good JavaScript [69:55] developer, then I will definitely put a [69:57] closure related question in the [69:59] interview. [70:00] A programmer who understands closures [70:02] can clearly grasp JavaScript's internal [70:04] behavior, memory handling, and [70:06] asynchronous flow. [70:08] JavaScript was originally created just [70:10] for small interactive tasks in the [70:12] browser. But now, you can build a [70:15] large-scale applications, even back-end [70:18] systems with it. The reason behind this [70:20] is powerful concepts in JavaScript like [70:22] closures, prototypes, and more. [70:25] Many people say, "I know var, let, [70:27] const. So, tell me about closures." But [70:30] as you have seen, var, let, and const [70:32] aren't that simple, either. This is [70:35] where the understanding of closures [70:37] begins. So, this was my detailed [70:39] tutorial on closures for today. If [70:41] watching it all at once feels [70:43] overwhelming, you can break it into [70:44] parts and watch it step by step. We have [70:47] tried to explain the whole topic very [70:49] simply, step by step. If there are any [70:51] mistakes or if it took so long, we [70:54] sincerely apologize. Still, I believe if [70:56] you go through the entire tutorial, you [70:58] won't have any confusion about closures. [71:01] And from now on, you will never be [71:03] intimidated by the word closure again. [71:06] Thank you, everyone. [71:11] You write JavaScript log a variable [71:15] and boom, undefined or even a scary [71:18] reference error. What just happened? [71:21] Let's finally understand what's going on [71:23] once and for all with a real story. Meet [71:26] Sam. Every morning, Sam goes to a coffee [71:29] shop. One day, before the waiter even [71:32] arrives, Sam shouts, "I'll have my [71:34] regular coffee." The waiter is confused. [71:37] Um, "We haven't even given you the menu [71:39] yet, sir." Turns out, they changed the [71:41] menu yesterday. No more regular coffee. [71:44] This is exactly what happens when you [71:47] try to use a variable before declaring [71:49] it. You're shouting at JavaScript, "Give [71:52] me the value." But, JS says, "Hold on. I [71:56] haven't seen that variable yet." Now, [71:58] let's reveal the real twist. JavaScript [72:01] does know that the variable exists. It [72:04] just hasn't given it a value yet. Why? [72:07] Because of something called hoisting. [72:10] Hoisting means lifting or moving [72:12] something above. JavaScript moves all [72:15] declarations, not values, to the top of [72:18] the scope. Let's first understand the [72:20] difference between declaration and [72:23] initialization. Declaration is when you [72:26] tell JavaScript that a variable exists. [72:29] Initialization is when you assign a [72:32] value to it. Check the example on the [72:34] screen. [72:35] Here, we have declared a variable called [72:37] coffee and assigned its value to latte. [72:41] So, var coffee is the declaration and [72:45] coffee equals latte is the [72:47] initialization. When we run this code, [72:50] we see undefined, not an error, because [72:53] behind the scenes JavaScript rewrote the [72:56] code like this. [72:58] So, var is hoisted and initialized as [73:02] undefined. Only the declaration part is [73:05] lifted or hoisted to the top of the [73:07] scope. This is called hoisting. It only [73:10] affects declarations. Initializations [73:14] stay where they are. That's why coffee [73:16] equals latte. This remains on the same [73:19] place or line. This is the first rule [73:22] you have to remember. We saw the use [73:24] case with var. What about let? Now we [73:28] will see how let and const behave. See [73:31] this example. [73:32] Here, we tried to log the value of T [73:35] before it was declared and initialized. [73:37] But this time, we get a reference error. [73:41] That means JavaScript has no reference [73:43] to the T variable at that point. [73:45] Surprising, right? It shows that let [73:49] behaves differently from var. Let's take [73:52] a closer look to understand what's [73:54] really going on. Because variables [73:56] declared with let and const are also [74:00] hoisted. [74:01] But they are kept in something called [74:03] the temporal dead zone. What does that [74:05] mean? Well, temporal dead zone is the [74:07] time between when the scope starts and [74:10] when the variable is declared. [74:12] The scope starts here and the variable [74:15] is declared here. During this time, the [74:18] T variable is in the temporal dead zone. [74:20] Which means in this period, the variable [74:23] exists, but you're not allowed to touch [74:25] it. Think of it like this. You're at an [74:28] event. There's a gift with your name on [74:31] it, but the host says, "Don't touch it [74:34] until I officially hand it to you." [74:36] If you touch it too early, boom, [74:39] reference error. Let's summarize this in [74:42] one simple table. Hoisting happens for [74:45] all, but only var is accessible before [74:48] the line where it's declared, but not [74:51] let and const. This is the second rule [74:54] you need to remember. So far, we have [74:57] seen hoisting in global scope. Now, [75:00] let's check what happens inside block [75:02] scope. Check the code example shown on [75:04] the screen. Here, the rule is also same. [75:08] Block scoped variables like let and [75:10] const hoist within that block only. Will [75:12] not go out of the block and are still in [75:15] temporal dead zone. And var is function [75:17] scoped, not block scoped. So, it still [75:21] works badly even inside a block. Simple. [75:24] Now, see what happens for functions. [75:27] Function declarations are fully hoisted [75:30] including the body. So, you can call [75:32] greet before it's declared and it works [75:35] fine. But, this doesn't work because say [75:38] bye is a const. So, it follows the [75:41] temporal dead zone rule, not the [75:43] function rule. Same rule applies to the [75:46] arrow functions. So, function [75:48] declarations and function expression [75:50] works differently. [75:52] Here are my tips or best practices to [75:54] avoid hoisting confusion. [75:57] Always declare variables at the top of [75:59] their scope. Use let and const. Avoid [76:03] var. Don't rely on hoisting. It's a [76:06] behavior, not a feature. Structure your [76:08] functions to read top down. Use linters [76:11] like ESLint. They can catch temporal [76:13] dead zone bugs. Here's the mindset tip I [76:16] promised. Think of hoisting as [76:18] JavaScript's preprocessing stage. It [76:21] scans your code before running it, [76:23] pulling up declarations, [76:25] but not their values. So, next time your [76:28] code acts weird, don't panic. [76:31] Check for hoisting. Check for temporal [76:34] dead zone. And write your code like you [76:36] respect the timeline. [76:38] Thanks for watching this complete guide [76:41] to JavaScript hoisting. If this helped [76:44] you, like the video, write a comment, [76:46] "Hoisting makes sense now." Keep [76:49] learning and keep building. See you next [76:51] time. [76:56] Hi everyone. Hope you all are doing [76:57] well. Today's topic is JavaScript's [76:59] execution context. I wanted to make sure [77:02] we first cover the fundamental concepts [77:04] of JavaScript before diving deep into [77:06] execution context. Once you finish [77:08] watching today's video, you will realize [77:11] that many of the topics we discussed [77:12] earlier, like scope, hoisting, and [77:15] closures, will start making much more [77:17] sense and feel newly discovered from a [77:20] deeper perspective. We already have a [77:22] preliminary idea about these topics. So, [77:24] today, through the lens of context, [77:26] we're going to rediscover all those [77:29] concepts by understanding execution [77:31] context in a completely new way. And by [77:34] the end, you will finally understand how [77:36] everything connects together. How two [77:39] hands make four. So, without wasting any [77:41] more time, let's get started. Before [77:43] diving into JavaScript context, let's [77:45] take a step back and see how JavaScript [77:47] actually runs, whether in a browser or [77:50] in a terminal. You might be wondering [77:52] why I'm mentioning the terminal. Well, [77:54] that's because JavaScript now also runs [77:56] outside the browser through Node.js. So, [77:59] let's first explore how that happens [78:01] behind the scenes. So, the code you [78:03] write in JavaScript, when it reaches the [78:05] browser, or in the case of Node.js, the [78:07] server, it's ultimately executed by the [78:09] computer. But, here's the thing. [78:12] Computers don't understand JavaScript. [78:14] They only understand binary or machine [78:17] language. So, somehow, the browser has [78:20] to translate our JavaScript code into [78:22] machine language so that the computer [78:24] can actually run it. That means there [78:26] must be some kind of mechanism inside [78:29] the browser or in the Node.js runtime [78:32] that performs this translation from our [78:34] programming language to machine [78:35] language, right? Exactly. That mechanism [78:38] inside the browser is called the [78:40] JavaScript engine. In Google Chrome, [78:42] this engine is known as the V8 engine. [78:45] Other browsers use their own engines. [78:47] Firefox uses SpiderMonkey, Internet [78:50] Explorer uses Chakra, and Safari uses [78:52] JavaScript Core. [78:54] No matter which engine it is, every [78:56] browser has one, and they all perform [78:58] the same core task, converting our [79:00] JavaScript code into machine language. [79:03] Different browsers may implement this [79:04] process in their own way, but all of [79:06] them follow the same standard, known as [79:09] the ECMAScript specification. ECMAScript [79:11] is basically the official standard that [79:14] defines how JavaScript should work, like [79:16] ES5, ES6, and so on. Since each [79:19] browser's engine implements the standard [79:22] slightly differently, sometimes the same [79:24] piece of code may produce slightly [79:26] different outputs in different browsers. [79:28] Anyway, once our code reaches the [79:30] browser, it's handed over to the [79:32] browser's JavaScript engine. The engine [79:34] then converts that code into machine [79:36] language, which the computer can finally [79:38] understand. And that's how we get to see [79:40] the output displayed on our screen. So, [79:43] that's the overall top-level view of how [79:45] JavaScript code runs. Now, as [79:47] programmers, we don't really need to [79:49] understand what happens at the hardware [79:51] level, because our focus isn't building [79:53] hardware. We are application developers. [79:56] What truly matters for us as JavaScript [79:58] developers is understanding what happens [80:01] inside the engine when it runs our code. [80:04] In other words, we need a clear picture [80:06] of how the JavaScript engine actually [80:08] compiles and executes our code. That's [80:10] the foundation of everything. So, let's [80:13] start right there. But before we do, [80:15] there's one important thing I should [80:16] mention. I have been talking mostly [80:18] about browsers, so you might be [80:20] wondering what happens in the case of [80:22] Node.js? Well, Node.js actually uses the [80:25] same V8 engine that powers Google [80:26] Chrome. Ryan Dahl, the creator of [80:29] Node.js, is a truly brilliant [80:31] programmer. What he did was take [80:33] Chrome's V8 engine, which was already [80:35] built, tested, and extremely fast, and [80:38] use it outside the browser. V8 is one of [80:41] the most powerful and highly optimized [80:43] compilers in the existence. It converts [80:46] JavaScript into machine language with [80:48] incredible speed and efficiency. That's [80:51] why Google Chrome performs so well [80:53] because of the V8 engine. Ryan Dahl [80:55] realized that V8 was already the best [80:57] engine out there. So, he thought if he [81:00] could extract it and use it outside the [81:02] browser, he wouldn't need to build a new [81:04] engine from scratch. The compilation [81:07] part would already be handled by V8. [81:09] Since V8 was written in C++, Ryan [81:12] integrated it directly into his own C++ [81:15] program. In other words, his C++ code [81:18] and the V8 engine were combined, and [81:21] that's how the Node.js runtime was [81:23] created. Now, let's take a look at what [81:25] actually happens inside a JavaScript [81:27] engine when it compiles JavaScript code. [81:30] To understand that, we need to start [81:31] with a bit of history. [81:33] When JavaScript was first introduced, it [81:35] was an interpreted language, meaning [81:38] there was no compilation process. There [81:40] wasn't a compiler to convert JavaScript [81:42] into efficient machine-level code. And [81:45] here, we come across two important [81:47] terms: interpretation and compilation. [81:51] At first, interpretation and compilation [81:53] might sound like the same thing because [81:55] both convert our code into machine code, [81:57] right? [81:58] That's true in essence, but the way they [82:00] work is completely different. Let's take [82:02] a closer look at the difference between [82:04] interpretation and compilation. Here, we [82:07] have some JavaScript code written by us. [82:09] This code is readable to humans, but the [82:11] computer doesn't understand it. So, what [82:14] does a computer understand? It only [82:16] understands binary, zeros and ones. [82:19] That's machine language, and while the [82:21] computer understands it perfectly, we [82:24] humans can't read it. [82:25] So, our job is to take the human [82:28] readable JavaScript code and convert it [82:30] into machine code so the computer can [82:32] understand what we are asking it to do. [82:34] There are three main ways to perform [82:36] this conversion. Interpretation, [82:38] compilation, and the number three is a [82:41] hybrid approach, a mixture of both. [82:44] Back in the '90s, JavaScript used to be [82:46] a purely interpreted language. But in [82:49] recent times, modern JavaScript engines [82:51] use a combination of both interpretation [82:54] and compilation to translate code into [82:56] machine language. The language itself [82:59] hasn't changed. It's still that [83:01] JavaScript, but the way it's implemented [83:04] has evolved dramatically. Now, let's see [83:07] how an interpreter actually works. How [83:09] JavaScript code gets converted into [83:11] machine code through interpretation. [83:13] Inside the interpreter, there's already [83:15] a set of equivalent machine instructions [83:17] for every command or expression we [83:19] write. For example, look at this piece [83:21] of JavaScript code. It contains several [83:24] lines of instructions. The interpreter [83:26] already knows the corresponding machine [83:28] level operations for each of these [83:30] lines. [83:31] Suppose we have a variable where two [83:33] numbers are being added. That's an [83:35] arithmetic operation. Then, in the next [83:37] line, there's a console log statement [83:39] that prints something on the screen. [83:42] And there could be many more such [83:43] instructions in our code. [83:45] For every one of these, the interpreter [83:47] has a predefined binary or machine code [83:50] equivalent, which tells the computer [83:52] exactly how to execute that particular [83:54] command. [83:55] So, we can visualize it like this. When [83:58] we run a program, the interpreter starts [84:00] executing the instructions line by line. [84:03] First, it looks at the first line where [84:05] two numbers are being added. The [84:07] interpreter already knows how to handle [84:09] that operation. So, it takes that [84:11] instruction, translates it into binary, [84:13] and executes it. Once the first line is [84:16] done, it moves to the next line. [84:18] Let's say that's a console log [84:20] statement. The interpreter knows how to [84:22] execute that, too. So, it runs it. Then [84:25] it moves to the next line and the next [84:27] and so on. But, there's a problem. This [84:30] process is quite slow because the [84:31] interpreter has to execute one line at a [84:34] time, constantly going back and forth [84:36] between reading the script and executing [84:38] it. This repeated process makes pure [84:40] interpretation significantly slower. [84:43] That's why JavaScript was very slow back [84:45] in the '90s. However, this process did [84:47] have one big advantage. You might [84:49] wonder, if it was so slow, why was it [84:52] designed this way? The reason is that [84:54] JavaScript was very easy to debug at [84:56] that time. [84:57] Here's why. The interpreter executes one [85:00] instruction at a time. So, if it [85:02] encounters an error while running any [85:04] particular line, it can immediately stop [85:06] and notify the programmer exactly where [85:08] the problem occurred. [85:09] This made debugging much easier because [85:12] developers could instantly identify the [85:13] issue, fix it, and continue running the [85:16] code. [85:17] So, the advantage of interpretation was [85:19] that it was easy to debug. But, the [85:21] downside was that it was slow. To [85:23] overcome that slowness, the concept of [85:26] compilation was introduced. Let's now [85:28] see how compilation works. A compiler [85:31] works differently. Instead of executing [85:33] code line by line, it takes the entire [85:35] program at once, translates the whole [85:37] thing into machine code, and then runs [85:39] it line by line from that compiled [85:41] version. This makes the process much [85:43] faster compared to interpretation. [85:46] However, there's a problem here, too. [85:48] Suppose there's an error in one of the [85:50] lines of code. The compiler won't stop [85:52] there. It will continue compiling the [85:54] rest of the code. That means if your [85:57] program contains any malicious or faulty [85:59] logic, for example, an infinite loop or [86:02] a piece of code that causes a memory [86:03] leak, it might still get executed and [86:06] potentially crash your system. You won't [86:09] have the chance to stop it midway like [86:11] in the interpreter's case. So, that's [86:13] the major drawback of compiled [86:15] languages. They can crash the system and [86:18] are harder to debug. Why? Because the [86:20] entire code gets compiled first, so we [86:22] don't immediately know which exact line [86:25] contains the error or bug. To find that [86:27] out, we have to run the program first, [86:29] and only then can we detect where the [86:31] problem is. [86:32] In short, with interpretation, we had [86:35] the advantage of easy debugging but [86:37] slower execution. On the other hand, [86:39] compilation gives us speed but makes [86:42] debugging difficult and increases the [86:44] risk of system crashes. So, imagine if [86:46] there were a way to combine both to get [86:49] the best of both worlds, fast execution [86:52] and easy debugging. That's exactly what [86:54] Google Chrome did in 2008 when they [86:56] introduced the V8 engine. They combined [86:59] these two approaches into a single [87:01] system and called it a just-in-time [87:03] compiler or JIT compiler. This JIT [87:07] compiler merges the easy debugging [87:09] nature of interpretation with the [87:10] high-speed execution of compilation, [87:13] creating a highly optimized and balanced [87:15] process. [87:17] This approach might not be as fast as [87:19] fully compiled language, but it's [87:21] definitely fast enough that users can't [87:23] tell the difference in real-world [87:25] performance. Now, let's see how the JIT [87:27] compiler actually works. [87:29] In JIT, the just-in-time part behaves [87:32] like an interpreter. It reads the code [87:34] while the compiler part translate it [87:36] into machine code. [87:38] Here's what happens. When we write our [87:40] JavaScript code, the JIT compiler [87:42] doesn't immediately compile the entire [87:44] thing. Instead, it keeps the code as it [87:46] is. When a particular function or [87:48] instruction is invoked, say for example [87:51] the instruction one function, the JIT [87:53] compiler instantly compiles that [87:55] specific function into machine code, [87:57] executes it, and returns the result. [88:00] Now, suppose we call another function, [88:02] instruction two, and an error occurs [88:05] inside it. The JIT compiler would [88:07] immediately detect it and say, "I have [88:09] just-in-time compiled this function, and [88:12] there's an error here. Stop right there. [88:14] This allows the programmer to instantly [88:16] see where the issue is and fix it, [88:19] maintaining both speed and debugging [88:20] flexibility. [88:22] That means we can still debug easily, so [88:24] it's both easy to debug and fast enough [88:26] to run efficiently. In other words, it's [88:29] truly the best of both worlds. That's [88:32] the core feature of the JIT compiler, [88:34] and this is exactly how modern [88:35] JavaScript engines, including Node.js, [88:37] work today. They compile JavaScript [88:40] through just-in-time compilation. I hope [88:42] this part is clear to you. So, with that [88:44] understanding, let's move on to today's [88:46] main topic, JavaScript's execution [88:49] context. Many people start learning [88:51] directly from execution context, but I [88:54] personally believe it's important to [88:55] first understand how the compilation [88:57] process actually works. Now that you [89:00] have that foundation, when we dive into [89:02] execution context, your brain will be [89:04] able to connect both parts and visualize [89:06] the complete picture of how JavaScript [89:08] truly operates. So, let's move on to our [89:11] main topic, JavaScript execution [89:13] context. In my opinion, execution [89:16] context is the most important concept in [89:18] JavaScript. The reason is simple. If you [89:20] truly understand how it works, then [89:23] advanced topics like hoisting, scope, [89:25] scope chain, and closures will become [89:27] incredibly easy to grasp. Let's start by [89:29] thinking about how we usually write [89:31] code. One common strategy is to break [89:33] our code into smaller parts. These [89:35] separate pieces of code can have [89:37] different names, like functions, [89:39] modules, or packages. But no matter what [89:42] you call them, their purpose is the [89:44] same, to break a complex program into [89:46] smaller, more manageable chunks. This [89:49] division reduces complexity and makes [89:52] our code easier to read, maintain, and [89:54] debug. [89:55] On the screen, we can see an example. On [89:58] the left side, there's a block of code, [90:00] and on the right side, the same code is [90:02] divided into smaller functions. At first [90:04] glance, the code on the left might look [90:06] simpler, but if you look closely, it's [90:09] not really practical. In this example, I [90:12] have represented each action with a [90:14] simple console.log statement, just for [90:16] easy understanding. But, in a real-world [90:19] application, things aren't that simple, [90:21] right? [90:22] Instead of just console logs, there [90:23] would be complex logic, multiple [90:25] algorithms, API calls, and data [90:27] processing happening behind the scenes. [90:29] Now, imagine if we wrote all those [90:31] complex operations like taking orders, [90:34] processing them, and completing them all [90:36] inside a single file or function. That [90:39] would make our code neither easy to read [90:41] nor easy to maintain. It would quickly [90:43] become messy and difficult to debug. [90:46] But, if I break each task into smaller [90:48] functions like the ones on the right [90:50] side, it becomes much easier to [90:52] maintain, and the overall complexity of [90:54] the code decreases significantly. In the [90:56] same way, JavaScript also break down our [90:59] code into smaller parts before [91:00] interpreting it. This helps reduce the [91:03] complexity of execution. Each of these [91:05] smaller units is what we call an [91:07] execution context. That's the simplest [91:10] definition you can think of. An [91:11] execution context is basically a small, [91:14] isolated environment where a specific [91:17] piece of code is interpreted and [91:19] converted into machine language. So, to [91:22] make its job easier, the JavaScript [91:24] engine divides our code into smaller [91:26] parts and executes them one by one. Each [91:28] of those parts is an execution context. [91:31] In today's session, we won't be writing [91:33] any code. Instead, I will walk you [91:35] through how execution contexts are [91:37] actually created inside the JavaScript [91:39] engine, line by line, so you can clearly [91:42] visualize what happens behind the scenes [91:44] when your code runs. Let's imagine the [91:46] left side of the screen is our code [91:48] editor, where we'll be writing the code, [91:51] and the right side will show how the [91:53] execution context is created. Now, at [91:55] this point, the left side, our code [91:57] editor, is completely empty. Even when [92:00] there's no code written yet, JavaScript [92:02] still creates something called a global [92:04] execution context right at the very [92:06] beginning. So, what exactly is this [92:08] global execution context? Think of it as [92:11] a simple object, or you can visualize it [92:14] as a box, a container that holds [92:17] everything your program needs to start [92:19] running. [92:20] At the very start, before any code is [92:22] executed, this global execution context [92:25] is created. [92:26] Inside it, the first thing we have is [92:28] the window object, which I'm sure you [92:31] are already familiar with. Next, we have [92:33] the this keyword, which initially points [92:36] to the window object. [92:38] Then comes the variable object, and [92:40] finally, another structure called the [92:43] scope chain. [92:44] There's one more important thing to [92:46] understand. The global execution context [92:48] actually goes through two distinct [92:50] phases. [92:51] When the program runs for the very first [92:53] time, it enters what's called the [92:54] loading phase, or creation phase. [92:57] During this phase, your code doesn't [92:59] execute yet. [93:01] To summarize, when the global execution [93:03] context is first created, it contains [93:05] four main components: window, this, [93:08] variable object, and scope chain. [93:10] And before any line of code runs, [93:13] JavaScript first goes through the [93:14] loading phase. [93:16] Now, let's assume we have written some [93:18] code. It's just a short seven-line [93:20] script where we have a variable named [93:22] topic and a function called get topic [93:25] that simply returns that topic. As we [93:27] have just discussed, when the global [93:29] execution context is created, it already [93:31] includes window, this, variable object, [93:34] and scope chain. Along with that, during [93:36] the loading phase, any functions and [93:38] variables declared in our code, like [93:40] topic and get topic, also get added to [93:43] the global execution context. But, [93:45] here's an important point. During the [93:47] loading phase, these variables and [93:49] functions are only recognized, not yet [93:51] fully executed. That means their values [93:54] are temporarily set to undefined until [93:57] the actual execution begins. As I [94:00] mentioned earlier, there's something [94:02] inside the global execution context [94:04] called the variable object. During the [94:06] loading phase, JavaScript allocates a [94:09] specific space in memory for every [94:11] variable declared in the code. So, for [94:14] example, a memory slot is created for [94:16] our variable topic, and JavaScript [94:19] assigns it the value undefined at this [94:21] stage. [94:22] Similarly, the get topic function is [94:25] also stored that same variable object. [94:28] But, instead of assigning it as [94:30] undefined value, JavaScript stores a [94:33] reference to the function, meaning the [94:35] function's entire structure or body is [94:38] saved somewhere in memory. So, now [94:40] through the global execution context, [94:42] JavaScript already knows that there's a [94:44] function called get topic defined in the [94:46] program. It hasn't executed it yet, but [94:50] it's aware that such a function exists [94:52] and might need to be called later during [94:54] execution. Once the creation phase is [94:57] complete, JavaScript moves on to the [94:58] second phase, the execution phase. In [95:01] this phase, the program starts running [95:03] from the very beginning, line by line. [95:06] So, when execution begins, it looks at [95:08] the first line, var topic is equal to [95:11] JavaScript execution context. Now, [95:14] JavaScript already knows the variable [95:16] name topic because during the loading [95:18] phase, it had already stored it in [95:20] memory with the value undefined. [95:23] When the execution phase starts, [95:25] JavaScript simply replaces that [95:27] undefined with the actual value we have [95:30] assigned. [95:31] This is the first time the code truly [95:33] gets executed. During the creation [95:36] phase, JavaScript also stored the get [95:38] topic function in its memory. It knows [95:41] that somewhere in this program, there's [95:43] a function called get topic. So, when it [95:45] reaches line seven, where the function [95:47] is called, it retrieves that function [95:49] reference from memory and executes it. [95:53] Now, imagine we write console.log topic [95:56] at the very top of our code, meaning we [95:59] are trying to use the variable before [96:01] it's even declared. [96:02] In earlier tutorials on JavaScript [96:04] hoisting, I explained this concept, but [96:07] not in this much detail. Not in the [96:09] context of the execution context. Back [96:12] then, I said that during hoisting, [96:14] JavaScript conceptually moves all the [96:17] variable declarations to the top of the [96:19] scope. Though, only the declarations, [96:21] not the actual values. But now, through [96:24] the lens of the execution context, you [96:26] will understand what really happens [96:28] behind the scenes. [96:29] As we saw earlier, during the loading [96:31] phase, JavaScript already stored the [96:33] variable topic in memory and assigned it [96:37] the default value undefined. That's why [96:40] when we try to print topic in the very [96:42] first line, before it's declaration, the [96:44] console will show undefined, which is [96:47] the value set during the loading phase. [96:50] Then, when the program enters the [96:52] execution phase and reaches the line var [96:54] topic is equal to JavaScript execution [96:56] context, if we place our console log [96:58] after that line, we will see the correct [97:01] value, right? That's because during [97:03] execution, when JavaScript encounters [97:05] this line, it updates the value of the [97:08] topic variable in the execution context [97:10] from undefined to JavaScript execution [97:13] context. Since the value is now updated, [97:16] any console log that runs after this [97:18] point will display the correct value. [97:21] So, if you have watched my earlier [97:23] tutorial on hoisting and now you are [97:24] watching this video, you will finally [97:26] understand why this hoisting behavior [97:28] happens inside the JavaScript engine. [97:31] In that tutorial, I explained hoisting [97:33] as variables being moved to the top, [97:36] which was just a simplified way to help [97:38] you visualize it. But now, through [97:40] execution context, you can see what [97:43] actually happens behind the scenes. [97:45] I hope this part is crystal clear now. [97:48] To summarize, the global execution [97:50] context is basically a JavaScript [97:52] object. At the very beginning, it [97:54] contains the window object if you are in [97:57] a browser environment or the global [97:59] object if it's Node.js. There's also a [98:02] this object that points to the same [98:04] window or global. [98:06] Then, all the variables declared in our [98:08] code are stored inside something called [98:10] the variable object. [98:12] And any functions we define are also [98:14] stored there, but only as references. [98:17] Meaning, JavaScript just keeps a pointer [98:19] to their full body in memory. [98:22] Then, when the program enters the [98:23] execution phase and reaches the line var [98:26] topic is equal to JavaScript execution [98:27] context, if we place our console.log [98:30] after that line, we will see the correct [98:32] value, right? [98:33] It also keeps something called a scope [98:35] chain. As we know, JavaScript uses [98:38] lexical scoping, meaning each function [98:40] knows exactly where it was written and [98:43] can access variables from its outer [98:45] scopes. So, JavaScript maintains all [98:47] these scopes together inside the scope [98:49] chain. That was the visual [98:51] representation of the global execution [98:53] context. Now, let's go a bit deeper. By [98:56] this point, you have already understood [98:58] how the global execution context works. [99:01] The good news is that after this, you [99:03] only need to understand one more type of [99:06] execution context, the function [99:07] execution context. And the interesting [99:10] thing is, it's almost identical to the [99:12] global execution context. The only [99:14] difference is that it's created every [99:16] time a function is called. [99:18] Let's quickly recall what happened [99:20] inside the global execution context. It [99:22] created a global object, created a this [99:25] object, allocated memory for variables [99:27] and functions, and initially assigned [99:30] all variables the value undefined, [99:33] right? Now, if you think carefully, [99:35] which of these four steps do you think [99:37] won't be necessary when a function gets [99:38] executed? [99:40] Exactly. The global object shouldn't be [99:42] created again inside a function [99:44] execution context because the entire [99:47] program already has one global object [99:49] that was created earlier and all [99:51] functions can access it when needed. [99:54] So, instead of creating a new global [99:55] object, something new happens inside the [99:58] function execution context. It creates [100:00] an arguments object. This object holds [100:03] all the parameters passed to that [100:04] function. That means whenever we define [100:07] a function in JavaScript and it has [100:09] parameters, JavaScript automatically [100:11] creates an object called arguments [100:12] inside that function's execution context [100:15] to store those values. [100:17] If we write console.log arguments inside [100:19] the function body, you will see all the [100:21] past parameters neatly stored as [100:23] key-value pairs within that arguments [100:26] object. So, the only structural [100:28] difference between the function [100:29] execution context and the global [100:31] execution context is this: the global [100:33] one contains a global object while the [100:36] function one contains an arguments [100:38] object. Everything else remains exactly [100:40] the same. [100:41] Simply put, think of the global [100:43] execution context as an entire world. [100:46] Whenever you call a function, a new [100:48] world is created inside that global [100:50] world following the same structure and [100:52] behavior. [100:53] I hope that makes the idea clear. When a [100:56] function is called, JavaScript creates a [100:58] completely separate execution context [101:00] for it. Inside that context, it builds [101:02] an arguments object to hold all the [101:05] parameters, creates a this object as [101:07] usual, and allocates memory for all the [101:10] variables and inner functions defined [101:12] inside that function. [101:13] That means hoisting also applies inside [101:16] functions. During the creation phase, [101:18] JavaScript will assign undefined to all [101:21] variables within that function and [101:23] that's exactly why hoisting happens [101:25] there, too. And this is how the function [101:27] execution context works. Now, remember [101:30] how we said that in JavaScript one [101:32] function can contain another function? [101:34] That means there can be multiple [101:36] execution context. The global execution [101:38] context is always there and alongside it [101:41] multiple function execution context can [101:43] be created as different functions are [101:46] called. So obviously JavaScript needs a [101:49] way to keep track of all these contexts [101:51] somewhere. And since JavaScript is a [101:53] single threaded language, meaning [101:54] everything runs on one main thread, that [101:57] same thread is also responsible for [101:59] managing all these execution contexts, [102:01] creating them, stacking them and [102:03] clearing them one by one. JavaScript [102:06] actually stores these contexts one on [102:08] top of another, just like a stack. And [102:11] this is stacking structure is called the [102:12] execution stack or more commonly the [102:15] call stack. At the very beginning [102:17] JavaScript places the global execution [102:19] context at the bottom of the stack. Then [102:22] whenever a function is called a new [102:24] function execution context is created [102:26] and pushed on top of it. If that [102:28] function calls another function inside [102:30] it, another context is stacked above [102:32] that and so on. In this way JavaScript [102:35] keeps adding and removing execution [102:37] contexts in a stacked order as the [102:39] program runs. So now we have a complete [102:42] picture of what an execution context [102:44] really is. It's made up of two types, [102:47] the global execution context, the [102:48] function execution context. Now let's [102:51] move on to something a bit more [102:52] advanced. So far we have only seen how [102:55] the execution context works in the [102:57] global scope or when a function is [102:58] called directly from the global scope. [103:00] But what if we have multiple functions [103:03] or if one function contains another [103:05] function, in other words, nested [103:07] functions? [103:09] How does the execution context behave [103:10] then? [103:11] Because every time JavaScript creates an [103:13] execution context, it needs to keep [103:15] track of them somewhere in memory. There [103:17] has to be some logic to determine which [103:20] context should run first and which one [103:23] should execute next. To manage all of [103:25] that, JavaScript needs to maintain a [103:28] specific data structure, right? And that [103:31] data structure is called the execution [103:33] stack. It's actually based on a stack [103:35] data structure. Think of it like [103:37] stacking books on a shelf. You place one [103:40] book on top of another. Similarly, [103:42] JavaScript stacks each execution context [103:45] on top of the previous one inside the [103:47] execution stack. [103:48] Now, a stack has one special property. [103:51] The last item that goes in is always the [103:53] first one to come out. In short, it [103:56] follows the LIFO rule. That means last [103:58] in, first out. [104:00] All right. Let's connect this idea with [104:02] our code. We know that whenever we run a [104:05] JavaScript program, the global execution [104:07] context is created first. Whether our [104:09] file contains code or not, this global [104:12] context will always be created [104:13] automatically. And once it's created, [104:15] JavaScript places this global execution [104:17] context at the very bottom of the [104:19] execution stack. That's where everything [104:22] begins. [104:23] Next, let's look at our code. Inside it, [104:26] we have three things. A variable [104:28] declared with var A, [104:30] a function called one with its [104:31] definition, and finally a call or [104:34] invocation of that function. These [104:36] three, the variable A, the function one, [104:39] and its invocation, all exist in the [104:41] global scope or the root level of the [104:43] program. [104:44] Inside the body of the one function, [104:46] there's another nested function called [104:48] two. And inside two, there's yet another [104:51] function called three. These nested [104:53] functions are not part of the global [104:54] scope. They belong to their respective [104:57] inner scopes. So, during the creation [104:59] phase, JavaScript stores the variable A [105:02] with the initial value undefined and [105:04] registers the body of the function one [105:06] with the variable object. Since there's [105:08] nothing else in the global scope, [105:10] JavaScript then moves on to the [105:12] execution phase. In this phase, [105:14] execution starts line by line. First, it [105:17] updates the value of A from undefined to [105:20] one. Then it moves to the next line, [105:22] where it finds the function definition [105:24] of one. Since that function's reference [105:26] is already stored in the variable [105:28] object, JavaScript skips over the [105:30] function body for now and continues to [105:32] the next line, the point where one is [105:35] actually invoked. [105:37] As soon as the one function is invoked, [105:39] JavaScript creates a brand new function [105:41] execution context inside the execution [105:43] stack, placed right above the global [105:46] execution context. When this new context [105:48] for one is created, it first enters its [105:51] loading phase. Since the one function [105:54] doesn't take any arguments, the [105:56] arguments object inside this execution [105:57] context will remain empty. [105:59] Then comes the this reference, which [106:02] points to the global object, in this [106:04] case, the window object. After that, we [106:06] have the scope chain and the variable [106:09] object. Inside the variable object, [106:11] there's only the two function. Why? [106:13] Because inside the body of one, there [106:15] are no local variables declared, only a [106:18] console.log statement that tries to [106:19] print A. But since the variable A is not [106:23] defined inside one, it doesn't appear in [106:26] this context variable object. Instead, [106:29] JavaScript will later look for it in the [106:31] outer scope using the scope chain. [106:34] However, the one function body does [106:36] contain another function declaration, [106:38] the two function. So, during the loading [106:40] phase, JavaScript stores the two [106:42] function inside the variable object, [106:44] just like it stored the function [106:46] definitions earlier in the global [106:47] execution context. It follows the exact [106:50] same process, only this time it's [106:52] happening inside the function's own [106:54] scope. [106:55] All right. Now, let's check if there's [106:57] anything else inside the body of one [106:59] function that needs to be added to its [107:01] variable object. The answer is no. [107:05] There's nothing else. So, next, [107:06] JavaScript moves to the execution phase, [107:09] and just like in the global execution [107:11] context, it starts executing line by [107:13] line. [107:14] The first line inside the one function [107:16] is console.log A. At this point, [107:19] JavaScript checks whether the variable A [107:21] exists inside the variable object of the [107:23] current execution context. It looks and [107:26] finds nothing. [107:28] Since the variable A isn't declared [107:30] inside the one function, JavaScript [107:31] moves to the next step. It follows the [107:33] scope chain to look into its parent [107:35] scope. Now, what's inside the parent [107:38] scope? Yes, the variable A is there, [107:41] defined in the global execution context. [107:44] So, JavaScript retrieves that value and [107:46] prints it in the console. It's important [107:48] to clearly understand one thing here. [107:50] The scope chain is essentially a lexical [107:53] environment. This means every scope is [107:55] connected to its parent scope in a [107:57] linked structure. The term chain is used [107:59] because each scope holds a reference to [108:02] its parent or ancestor scopes, forming [108:04] an actual chain-like connection. [108:07] That's why when JavaScript couldn't find [108:09] the variable A in the one function's own [108:11] variable object, it followed that chain [108:13] upward to its parent or ancestor scopes [108:16] and successfully found A in the global [108:19] scope. Hopefully, that part is clear. [108:21] Now, let's go back to the code flow [108:23] again. After printing the value of A, [108:26] the program moves to the next line. [108:28] There it finds the body of the two [108:29] function. But at this stage, JavaScript [108:32] doesn't need to do anything with it [108:33] because during the loading phase, the [108:35] reference to two has already been stored [108:38] in memory. So, it skips over the [108:40] function body and moves to the next line [108:42] where it sees that two is being invoked. [108:45] Since the two function is now being [108:47] called, JavaScript creates a brand new [108:49] function execution context for it and [108:51] places it on top of the execution stack. [108:54] Just like before, when this new two [108:57] execution context is created, it first [108:59] goes through its loading phase. During [109:02] this phase, it populates its scope [109:04] chain, meaning it links itself with the [109:06] variable objects of its parents or [109:08] ancestor scopes. Inside the body of two, [109:11] there's a variable named B. So, in this [109:13] new context variable object, JavaScript [109:16] stores B with the initial value [109:18] undefined. [109:20] Then it finds another function [109:21] definition, three. So, just like before, [109:24] JavaScript stores the reference to the [109:26] three function inside the variable [109:28] object of two. [109:30] Then, in the next line, the program [109:31] moves to where the function three is [109:33] called. [109:34] Since it's still in the loading phase, [109:37] there's nothing to execute yet. That [109:39] part is done. So, now it enters the [109:41] execution phase and starts running each [109:43] line one by one. Inside function three, [109:46] what's the first line? It's a console [109:48] log of the variable B. But that variable [109:50] hasn't been initialized yet. In this [109:53] context, its value is still undefined. [109:56] So, when the program runs that line, it [109:58] prints undefined. [110:00] Now, you can clearly see why during [110:02] hoisting, variables often print [110:04] undefined. Once you understand how the [110:07] execution context work, many other [110:09] tricky behaviors of JavaScript starts to [110:11] make sense. [110:12] So, pay close attention and try to grasp [110:15] these terms deeply. All right. After [110:17] that, in the next line, the variable's [110:19] value is being assigned. So, the value [110:21] of B changes from undefined to two. [110:24] Then, in the following line, we see the [110:26] definition of the three function. The [110:28] execution context doesn't need to do [110:30] anything here. So, it simply skips over [110:32] this line. The next line shows that the [110:35] three function is being invoked. And not [110:37] just that, it's being called with an [110:38] argument four. [110:40] Since the three function has been [110:41] invoked, a brand new execution context [110:43] is created inside the execution stack. [110:46] Now, pay close attention here. During [110:49] the loading phase of the three execution [110:50] context, we can already see that there's [110:52] a value inside the arguments. At index [110:55] zero, it's four. [110:57] That's because when the function was [110:58] called, the value four was passed in. [111:01] And here's something interesting. Look [111:03] at how we named the parameter inside the [111:05] three function. It's called D, right? [111:08] So, during the loading phase itself, a [111:10] variable named D appears inside the [111:12] context and it's already assigned the [111:14] value four. [111:16] Then it moves to the next line. There's [111:18] a console.log statement. Nothing special [111:20] happens there yet. After that, we have [111:22] let C is equal to three and this is [111:24] where things get a bit different. You [111:27] see, although var, let, and const are [111:30] all used to declare variables, their [111:32] behaviors are not the same. [111:34] For var, during the loading phase, [111:36] JavaScript automatically allocates [111:38] memory and sets its value to undefined. [111:41] But for let and const, JavaScript still [111:44] allocates memory during the loading [111:45] phase. The difference is they remain [111:48] inside what's called the temporal dead [111:50] zone or TDZ until the actual line of [111:53] code where they are declared is reached. [111:56] That means even though they exist inside [111:58] the execution context, they can't be [112:00] accessed through the variable object [112:01] yet. [112:02] Now, you might wonder what exactly is [112:05] the temporal dead zone? [112:07] It's the period between a variable being [112:09] created in memory and being initialized [112:11] with a value. [112:12] During this time, the variable [112:14] technically exists, but since no value [112:16] has been assigned, JavaScript keeps it [112:18] temporarily inaccessible. If you try to [112:21] access that variable during the TDZ, you [112:23] will immediately get a reference error. [112:25] In simple terms, the program knows that [112:27] the variable exists, but it's not ready [112:30] to be used yet. And until the code [112:32] execution reaches that specific [112:33] declaration line, you won't be able to [112:35] access it from the variable object [112:37] either. [112:38] You can think of it like an iPhone lock [112:40] screen. The phone is there, but until [112:42] you enter the PIN and unlock it, you [112:44] can't do anything with it. Now, many [112:46] people wonder, "Doesn't the same thing [112:48] happen with var? Why does JavaScript [112:50] assign undefined to variables declared [112:52] with var, but keeps let and const inside [112:55] the TDZ instead of doing the same?" [112:57] Excellent question. The main reason is [112:59] that var comes from the older versions [113:01] of JavaScript, specially ES5 and [113:04] earlier, where there was no concept of [113:06] safety checks or the temporal dead zone. [113:08] Back then, JavaScript didn't want the [113:10] program to crash if a variable was [113:12] accessed before initialization. So, to [113:15] avoid breaking the program, it would [113:17] automatically assign undefined as a [113:19] fallback value. Just try to be a bit [113:22] more smart. But, let and const were [113:25] introduced in ES6, where the goal was to [113:28] keep the language safer and more [113:29] predictable. If JavaScript had assigned [113:32] undefined to them as well, it would have [113:34] created the illusion that was properly [113:37] initialized even though it wasn't. So, [113:40] JavaScript intentionally blocks access [113:42] to those variables during that time to [113:44] signal to developers. The variable [113:46] exists, but it's not ready to be used [113:48] yet. [113:49] Hope that clears things up. Now, let's [113:51] get back to our flow. [113:53] At this point, inside the three [113:54] function, there's nothing else left to [113:56] load. So, it moves to the execution [113:58] phase. [114:00] In the first line, we have a console.log [114:02] printing C plus D. We already know that [114:05] the value of D is four, but the variable [114:07] C is still inside the temporal dead [114:09] zone. Meaning, it can't be accessed yet. [114:12] So, this line will throw a reference [114:13] error [114:14] because the program can't reference C [114:16] from memory at that point. However, if [114:19] we had written the code the other way [114:21] around, first declaring let C is equal [114:23] to three and then logging it in the next [114:25] line, the behavior would have been [114:27] completely different. In that case, [114:29] during the creation phase, C would still [114:32] start in the dead zone, but by the time [114:35] the execution reached that line, its [114:36] value would already be assigned. Then, [114:39] when the console.log ran, both C and D [114:42] would be accessible and their values [114:44] would print correctly. Clear now? So, [114:46] you can see how JavaScript actually [114:48] works behind the scenes. We have also [114:50] learned how hoisting truly operates at a [114:53] machine level through the concept of the [114:55] execution context. All right, now let's [114:57] move forward. Inside the three function, [115:00] once the console.log runs successfully, [115:02] it will print seven. After that, is [115:05] there anything else left in the [115:06] function? No, there isn't. Since there [115:08] are no more lines to execute, the work [115:10] of the three function is complete. And [115:13] whenever a function finishes its job, it [115:15] immediately gets popped out from the [115:17] execution stack. That means, since the [115:19] three function has finished executing, [115:22] it will be removed from the stack [115:23] following the LIFO. That means, last in, [115:26] first out rule. Now, who's at the top of [115:28] the stack? The two function. If we check [115:31] the body of two, do we see any remaining [115:33] lines to execute? No, it's done, too. [115:36] So, two will also exit from the [115:38] execution stack. [115:40] Finally, since there's nothing left to [115:42] run in one, that function will also pop [115:44] out, leaving the execution stack [115:46] completely empty. Since there are no [115:48] more functions left to execute, the [115:50] global execution context will also exit [115:52] from the execution stack. However, if [115:55] there had been more code to run in the [115:56] global scope, for example, another [115:58] function called right after one, then [116:00] the global execution context wouldn't [116:01] have been removed yet. Instead, it would [116:03] have continued executing the next [116:05] function just like before. [116:07] I hope by now you have no doubts left [116:09] about execution context. While learning [116:12] about it, we also discovered how [116:14] hoisting actually works, didn't we? Now, [116:17] let's move on to the another important [116:18] concept, scope. We have already [116:21] discussed scope before, but this time [116:23] we'll understand how scope works in [116:25] relation to the execution context. Take [116:27] a look at this simple example. Here, we [116:29] have a function called hello. Inside it, [116:32] there's a variable named message [116:34] declared with var, which holds a certain [116:36] value. [116:37] Outside the function, that is, in the [116:39] global scope, we are calling or invoking [116:41] the hello function, and in the next [116:43] line, we are trying to print the message [116:45] variable using console.log. [116:47] It's a very simple setup. So, based on [116:49] everything we have learned so far, what [116:51] will happen if we run this program? [116:53] First, the global execution context will [116:55] go through its creation phase. During [116:57] this phase, it will find a function [116:58] named hello and store its reference [117:01] inside the variable object. Once that's [117:03] done, there's nothing else left for the [117:05] creation phase, right? [117:07] Perfect. Now, the execution phase [117:09] begins. The first line is the definition [117:11] of the hello function. Since we're in [117:13] the execution phase, there's nothing to [117:15] execute here. The function's reference [117:17] is already stored in memory. So, the [117:19] program moves on to the next statement, [117:21] where the hello function is invoked. [117:24] As soon as that happens, a new execution [117:26] for the hello function is created. [117:28] Inside the creation phase of the hello [117:30] function's execution context, the [117:32] variable message is placed inside the [117:34] variable object with the value [117:36] undefined. Once the creation phase is [117:38] complete, the program moves to the [117:40] execution phase, where the variable [117:42] message gets its actual assigned value [117:45] instead of undefined. So, in the [117:47] execution phase, the value of the [117:49] message variable becomes hello world. [117:52] After that, does the hello function have [117:54] anything else to do? No, it doesn't. So, [117:56] the hello function's execution context [117:58] will now be popped off or destroyed. [118:00] That means the program returns to the [118:02] global execution context. [118:05] Now, what happens next? After the hello [118:07] function is invoked, the next line is [118:09] console.log message. So, the program [118:12] will now try to print message. But wait, [118:15] is the message variable declared inside [118:17] the global execution context variable [118:19] object? No, it isn't. That variable was [118:23] created inside the function execution [118:25] context. And when that function finished [118:27] executing, its execution context, along [118:30] with its scope chain and variable [118:32] object, was completely removed from [118:34] memory. [118:35] That's why when the console tries to [118:37] access message, JavaScript throws a [118:39] reference error. [118:40] Can you relate this now? Those of you [118:42] who have seen my video on a scope might [118:44] remember the example I gave. A child can [118:47] always access or inherit things from its [118:50] parent, but a parent can never access [118:52] what belongs to the child. Back then, it [118:55] was just an example, but now you can [118:57] actually visualize how the program [118:59] manages all of this behind the scenes. [119:02] That means, while understanding [119:04] execution context, we have rediscovered [119:06] the concept of scope in a much clearer [119:09] and more practical way. Now, let's move [119:11] on to another very important topic, [119:13] closure. [119:15] Just like we visualized execution [119:16] context earlier, we will now see how a [119:19] closure is created and how it works step [119:21] by step. [119:22] First, the program creates the global [119:24] execution context. We are now in the [119:26] creation phase. During this phase, the [119:28] program scans through the code and finds [119:30] a variable named sum and a function [119:32] named do sum. So, memory is allocated [119:35] for sum and its initial value is set to [119:37] undefined. The entire function [119:40] definition of do sum is stored in memory [119:42] as a reference. Once the creation phase [119:44] is complete, the execution phase begins. [119:48] In the execution phase, the first line [119:50] sets sum is equal to zero. Next, the [119:52] program skips over the do sum function [119:54] since it's only a definition. Then it [119:56] moves to the line var temp is equal to [119:58] do sum in the bracket two. Here, the [120:00] function is being called, so a brand new [120:02] function execution context is created [120:04] for do sum. Now, the creation phase of [120:06] that function execution context begins. [120:08] The parameter A receives the value two. [120:11] So, in memory, we have A is equal to [120:13] two. Inside the function, there's an [120:15] anonymous function being returned. That [120:18] function's reference also gets stored in [120:19] memory. Once the creation phase is done, [120:22] the execution phase starts. During this [120:25] execution phase, the do sum function [120:27] doesn't perform any calculation. [120:28] Instead, it simply returns that [120:30] anonymous function. When that happens, [120:32] the do sum execution context is popped [120:34] off the stack, but something very [120:36] important also occurs at that exact [120:38] moment. A closure is created. Why does [120:41] that happen? Because when the anonymous [120:43] function is returned, it still remembers [120:45] the data from its outer scope. In this [120:48] case, A is equal to 2. [120:50] Even though the do some function itself [120:51] gets destroyed, its lexical environment [120:54] doesn't disappear completely. JavaScript [120:56] realizes that this inner function might [120:59] be called again later, and when that [121:01] happens, it will need access to those [121:03] outer variables. So, it preserves that [121:06] environment in a separate structure [121:07] called the closure scope. Now, you can [121:10] understand JavaScript is really smart. [121:12] Next, the code moves to the line sum is [121:14] equal to sum plus temp 8. Here, the [121:18] function is called again, meaning temp 8 [121:20] is invoked. This creates a new execution [121:22] context for the anonymous function. [121:25] During its creation phase, the parameter [121:26] B is assigned the value 8. When the [121:29] execution phase begins, the function [121:31] executes return A plus B. [121:34] Now, since A doesn't exist in the [121:36] current scope, JavaScript follows the [121:38] scope chain and looks into the outer [121:40] scope, which is the closure scope. [121:43] There it finds A is equal to 2, performs [121:45] the calculation 2 plus 8 is equal to 10, [121:48] and returns the result 10. At that [121:50] point, the temp function's execution [121:52] context completes its job and gets [121:54] popped off from the stack. So, in the [121:57] line sum is equal to sum plus temp 8, [121:59] the value of sum was initially zero. [122:01] That means it becomes sum is equal to [122:03] zero plus 10. Now, where did that 10 [122:06] come from? It came from the temp [122:09] function's execution context. Now, you [122:11] can clearly see how a closure actually [122:13] works. A closure is basically a [122:16] mechanism that keeps a function [122:18] connected to its outer environment, even [122:21] after the outer function has been [122:22] destroyed. This is one of JavaScript's [122:24] most magical, yet completely logical [122:27] behaviors, and it all originates from [122:30] the concept of the execution context [122:32] itself. So, everything you have seen so [122:34] far, this is what JavaScript's execution [122:37] context truly is. By understanding just [122:40] this one topic, we have been able to [122:42] uncover how JavaScript actually works [122:44] behind the scenes. We discovered how [122:47] scopes are formed and how confusing [122:49] topics like closure and hoisting are [122:51] really operated logically within the [122:53] language. All this time, we used to just [122:56] repeat what we heard, that hoisting [122:58] means variable are lifted to the stop [123:00] and closure means a function stays [123:02] connected to its outer environment. But [123:05] after watching this video, you should [123:06] now have a clear inside-out [123:08] understanding of how and why JavaScript [123:11] behaves this way. From today, you may [123:13] not understand your wife, but you will [123:15] definitely understand JavaScript. [123:17] I have given my best effort to explain [123:19] this topic as clearly as possible. If [123:22] this video helped you understand these [123:23] concepts better, please don't forget to [123:25] like and comment. It truly encourages me [123:28] to keep making more videos like this. [123:30] And if you have any valuable feedback or [123:33] specific topics you'd like me to cover [123:35] next, feel free to let me know. Your [123:37] small words of motivation inspire me to [123:40] keep creating and sharing more. Thank [123:42] you so much for everything and thank you [123:44] so much for watching my videos. I will [123:46] see you again in another one. [123:52] From my personal experience, when I [123:53] started working with JavaScript, it was [123:55] back in 2008. At that time, JavaScript [123:57] was considered very trivial. People used [123:59] to say it was only for a few interactive [124:01] web features. But even in that era, [124:03] JavaScript already had the prototype [124:04] concept. Still, I personally didn't work [124:07] deeply with prototypes because I never [124:09] felt the need to. But over time, [124:11] JavaScript became one of the most [124:12] popular programming languages in the [124:13] world. If someone wants to learn [124:15] JavaScript, they can't skip prototypes [124:17] because the foundation of JavaScript is [124:19] prototypes. This is what makes [124:20] JavaScript different from many other [124:22] programming languages. Since I'm talking [124:24] about JavaScript, prototypes naturally [124:26] have to be part of the discussion. So, [124:28] that's why today's tutorial. I hope [124:30] after watching this tutorial, you won't [124:32] have any confusion about prototypes. [124:34] Let's get started. In JavaScript, you [124:36] can't go far without objects. Whatever [124:38] you do, almost everything is based on [124:40] objects. We know JavaScript is a [124:42] functional programming language, and [124:43] here functions themselves are objects. [124:46] That means in JavaScript, you can't even [124:48] imagine anything without objects. And [124:50] JavaScript's prototype concept is [124:52] connected to these objects. So, I don't [124:54] want to start with a theoretical [124:55] definition of prototypes. I will show [124:57] you step-by-step how objects are created [124:59] or instantiated. Then, gradually through [125:02] that process, we'll discover prototypes [125:04] on our own. If you understand this [125:05] through examples, it becomes easier to [125:07] understand, easier to remember, and the [125:09] concept becomes clearer. Let's start. [125:12] What's the most common way to create a [125:13] new object in JavaScript? The most [125:15] common way is this literal format. Let [125:18] person is equal to a blank object. And [125:20] just by adding curly braces, the object [125:22] gets defined, right? So, person is a [125:24] blank object. Now, if we want to add [125:26] properties to the person object, how do [125:28] we do that? Usually, we do it with dot [125:31] notation. So, we write person.name is [125:34] equal to Messi. So, now we gave the [125:36] person a name, Messi. Next, let's add [125:39] age. Person.age is equal to 38. Now, if [125:42] we want to add any method or function to [125:44] the person object, we can do that with [125:46] the same rule. In JavaScript, functions [125:48] behave like variables, and functions [125:49] themselves are objects. So, they can be [125:52] stored as object properties. So, let's [125:54] say we want to add a function inside the [125:56] person object. For example, humans eat. [125:58] So, we'll create a function called eat. [126:01] Person.eat is equal to function. Then, [126:03] we'll print something inside the [126:04] function. So, I will write here [126:07] console.log person is eating. So, now we [126:10] created an object that has regular [126:11] properties, and we also added a [126:13] function. Now, let's create another [126:15] function. What comes after eating? [126:17] Sleeping. So, let's create another [126:19] function called sleep. Person.sleep is [126:21] equal to function. And inside this [126:22] function, I will also write console.log [126:25] person is sleeping. So, we created a [126:27] person object and added different [126:28] properties and functions to it. But, in [126:30] real-life applications, we may need to [126:32] create many such person objects, right? [126:34] In object-oriented programming, in large [126:36] applications, we work with many objects. [126:38] Let's say, instead of person here, we [126:40] need to work with user objects and [126:42] create many users. So, what can we do in [126:45] that kind of situation? We can simplify [126:47] this a bit instead of doing person.eat, [126:49] person.sleep separately every time. But, [126:51] before that, let's cut the whole code we [126:53] wrote. Now, I will define a function. [126:55] Function person name, age. I named the [126:58] function person and passed name and age [127:00] as parameters. Now, inside this function [127:02] body, I will paste the code we cut [127:04] earlier. So, here we had person.name is [127:06] equal to Messi. Instead of hardcoding [127:08] Messi, since we took name as a [127:10] parameter, I'll write person.name is [127:12] equal to name. That means, instead of a [127:14] hardcoded name, now we are dynamically [127:16] taking the name from the parameter. And [127:18] similarly, for age, I'll write [127:19] person.age is equal to age. That means, [127:22] instead of the hardcoded 38, I'm taking [127:24] age from the parameter. This part should [127:26] be very clear to everyone. And finally, [127:28] since I made this a function, I want an [127:30] object back. So, at the end, I will [127:32] return the object from inside the person [127:34] function. Return person. All right. So, [127:37] this way we did the same thing as [127:38] before. We know functions themselves are [127:40] objects. To see that, here's what we can [127:42] do. console.dir person. This dir is [127:45] actually a slightly more advanced [127:47] version of console.log. We just passed [127:49] person. We didn't call it. So, what [127:51] happened? If we look in the browser [127:52] console, we get an object. Functions are [127:55] actually nothing special. In JavaScript, [127:57] functions are just another kind of [127:58] object. So, just like person is an [128:00] object, functions are also objects. So, [128:03] we can create objects this way, too. We [128:05] took the behavior of this person object, [128:07] meaning all kinds of properties and [128:08] methods, and put it into a function. [128:10] Now, if you want to create a real [128:12] person, what do we do? Let's say, the [128:13] person's name is Messi. Then, we can [128:15] write Messi is equal to person and pass [128:18] Messi and 38. That means, we are calling [128:20] the person function and passing Messi as [128:22] the name parameter and 38 as the age [128:24] parameter. So, by doing this, we are [128:26] creating a new person named Messi. [128:28] Again, if you want to create another [128:30] person, let's say Neymar, then we can [128:31] write Neymar is equal to person and pass [128:34] Neymar and 33. That means our Neymar is [128:36] created. So, we haven't learned anything [128:38] new yet, but I just showed you how to [128:40] create a function, return an object from [128:43] inside it, and use that function to [128:44] create real life-like objects. But, now [128:47] we can create many many people using [128:49] this person function. But, is there any [128:51] problem here? Can you guess? Well, when [128:53] we have only two persons in our program, [128:55] it's not a big deal. But, in larger [128:57] applications, creating so many objects [128:59] will fill up memory. So, if there are [129:01] countless persons like this, and we [129:02] create each one separately with its own [129:04] methods, performance will be affected in [129:06] large applications. So, to avoid that, [129:08] what you can do is share the methods. [129:10] That means the methods that are common [129:12] in our person function, the methods both [129:14] Messi and Neymar shared, like eat and [129:16] sleep, can be kept in a separate common [129:18] object. Then, when we create person [129:20] objects, we can reference those methods. [129:22] What I'm trying to say is, when we [129:24] create Messi and Neymar, we are creating [129:25] everything twice. That means, when the [129:27] person function is called for Messi, eat [129:29] and sleep are created again. Then, when [129:32] it's called for Neymar, eat and sleep [129:33] are created again. In one word, the body [129:36] of the person functions run every time [129:37] person is called. But, we can avoid [129:39] that. So, above, I wrote a new variable, [129:42] person methods is equal to blank. I [129:44] created an object called person methods. [129:46] Inside this, we'll keep the methods we [129:48] want to share, the common methods. In [129:50] our case, person mainly has eat and [129:53] sleep. I copied these two methods and [129:55] moved them into the person methods [129:56] object. Using shorthand method syntax, [129:58] we wrote in person methods. So, now we [130:01] have two methods inside a separate [130:02] object, and those methods are in person [130:04] methods. Now, what can I do? Inside the [130:06] person function, instead of creating the [130:08] methods directly, I can reference them [130:10] from person methods. We know that when [130:12] we reference something from an object, [130:14] nothing new is created. The methods in [130:16] person methods won't be created again, [130:17] because they are already there. I can [130:19] just reference eat and sleep from inside [130:21] the person function, like this, earlier [130:23] inside the person function body, we had [130:24] person.eat as a function. Now instead, I [130:27] will write person.eat is equal to person [130:29] methods.eat. I referenced eat from [130:32] person methods. And similarly for sleep, [130:34] I will write person.sleep is equal to [130:36] person methods.sleep. So, person now [130:38] references person methods.sleep as well. [130:40] What does that mean? No matter how many [130:42] people we create now, all of them will [130:44] use the same eat and sleep methods. [130:46] Person methods is just one object. It [130:48] isn't being recreated again and again. [130:51] So, a lot of memory is saved. Now we are [130:53] not recreating these methods repeatedly. [130:55] So, it looks like all problems are [130:57] solved, but still one problem remains. [130:59] Can you guess what it is? If we [131:01] introduce another method in person [131:02] methods, let's say play, and write [131:04] inside it console.log person is playing, [131:07] then we would have to go back to the [131:09] person function and reference that play [131:10] method there, too. That means we have to [131:12] change code in two places. That's a bit [131:15] annoying, because we are basically [131:17] working inside the person object, and [131:18] every time we need to reference from [131:20] another separate object. That's [131:21] definitely not nice approach. We can see [131:23] that clearly. So, what can we do? We [131:25] don't want this. We want person to be [131:28] able to automatically access whatever [131:30] methods exist in person methods, [131:32] whenever it needs them. To do that, we [131:34] will use a JavaScript feature called [131:35] object.create. We already created [131:38] objects using functions. Now, we can [131:40] also create objects using object.create. [131:43] If you don't know object.create, no [131:45] problem. I will explain it. First, let's [131:47] see how object.create works. For [131:49] understanding, we'll take a simple [131:51] object. Captain is equal to a blank [131:53] object. Now we created an object named [131:55] captain. Let's add some properties to [131:57] it. Name Messi, age 38, and country [131:59] Argentina. Now let's create another new [132:01] object. We will write player is equal to [132:03] object.create captain. Here, using [132:05] object.create, we created a new object [132:08] in the player variable based on the [132:09] captain object. That means using [132:11] captain, we created a new object called [132:13] player. That's what object.create does. [132:16] So, how is this actually working? We did [132:18] object.create and now if we log player, [132:21] let's write console.log player, what do [132:23] we get in the log? We get a blank [132:25] object. That means there's nothing [132:27] inside the player. But I'm saying I [132:29] created player from captain. So, what's [132:31] the benefit then? I'm still getting [132:33] blank object. Okay, yes, it looks blank, [132:36] but if I write console.log player.name, [132:39] now look, the output is Messi. Player is [132:41] blank, but when we access player's [132:42] properties, it's getting the properties [132:44] from captain. Similarly, if I write [132:46] player.age, I get age two. So, even [132:49] though player looks empty, we can still [132:51] access values through player. That means [132:53] the child object can access the parent's [132:55] properties. But how is that happening? [132:57] Player is actually blank. This is [132:59] object.create's behavior. JavaScript [133:01] understands that when we use [133:02] object.create, player is the child and [133:04] captain is the parent. When we write [133:06] player.age, JavaScript first checks [133:08] whether age exists in player. It [133:10] doesn't, so it looks in the parent, that [133:12] means captain. That's why we can access [133:15] captain's properties through player.name [133:17] or player.age. It checks whether captain [133:19] has age, sees that yes, age exists, and [133:23] then gives that value as the default. In [133:25] other words, JavaScript is doing [133:26] something extra smart here. This extra [133:29] smartness was designed to make the [133:30] programmer's life easier, but it also [133:32] creates confusion sometimes because the [133:35] behavior feels a bit unexpected. We [133:37] think, "Bro, player logs as blank, but [133:39] when I access properties, I get values." [133:41] Yes, that is exactly object.create's [133:44] behavior. But how does it work? This is [133:46] possible because of prototypes. [133:48] Object.create behaves this way because [133:50] of prototypes. For now, just remember [133:52] this much. With object.create, a child [133:55] can access the parent's properties. We [133:57] still haven't fully learned prototypes. [133:59] I just introduced the name. We'll see [134:01] how it works later. Now, let's go back [134:03] to the previous example. Inside the [134:05] person function, earlier we wrote person [134:07] is equal to blank, a blank object. Now, [134:09] instead of that, we'll write [134:11] object.create and pass person methods. [134:14] Here, person methods will be the parent [134:16] of person. So, now what can we expect? [134:18] The person object will automatically be [134:19] able to access all methods in person [134:21] methods, and we won't have to reference [134:23] them separately anymore. Now, assume the [134:25] code below doesn't exist. Just below the [134:28] object.create line, let's write [134:29] console.log person. Then we'll get a [134:32] blank object. If we check in the [134:33] browser, yes, we really get a blank [134:35] object. It's showing a blank object [134:37] twice because earlier we called person [134:39] twice for Messi and Neymar. So, it logs [134:42] twice. Even though person is blank, [134:44] properties like person.name and [134:45] person.age don't exist in the parent, [134:48] but person.eat and person.sleep, [134:50] person.play can automatically come from [134:52] the parent. That means person methods. [134:55] And we don't need to write person [134:57] methods.eat separately anymore. As we [134:59] saw earlier, we no longer need to write [135:01] person.eat, person.sleep, person.play [135:03] separately inside the person function. [135:05] So, those lines can be removed. Now, [135:08] after creating Messi and Neymar objects, [135:10] if we write Messi.play and call it like [135:12] that, the output comes. It works fine. [135:15] For Neymar, too, if we write [135:16] Neymar.play, that also works fine [135:18] because according to object.create's [135:20] behavior, person methods is the parent, [135:22] and the child can access the parent's [135:24] properties. That's why play is also [135:26] working. So, the previous problem, [135:28] having to write in both the person [135:30] function and person methods, is now [135:31] solved. But, we can improve this code [135:34] even more. What I have shown so far is [135:35] just a warm-up. What you saw is actually [135:38] a very familiar programming pattern. [135:39] Properties are shared from parent. Child [135:41] can access those properties, and it can [135:43] also add its own properties. But, for [135:45] such a simple pattern, we are creating a [135:47] separate object just to use as the [135:49] parent. Meaning, we need help from [135:51] another object outside person. That can [135:53] feel a little inconvenient. There should [135:55] be something built in for this, and [135:57] JavaScript does have it. In a popular [135:59] language like JavaScript, when we create [136:00] objects, the parent's properties should [136:02] be easily available to the child without [136:04] needing a separate object reference. [136:06] JavaScript has exactly that option. This [136:08] is where prototypes come in. Now, we [136:11] will understand what prototypes are. [136:12] Instead of starting with a theoretical [136:14] definition, let's first see an example. [136:16] Let's write a simple function. Function [136:18] test. So, we created a function called [136:20] test. It does nothing, completely blank. [136:23] We know functions are objects. Even [136:25] though test does nothing, if we write [136:27] console.log test.prototype, look, we get [136:29] something. We can see the test [136:31] function's body and inside it we can see [136:34] prototype as a property. And just write [136:36] console.dir test. Then we can also see [136:38] that there's a property named prototype [136:40] inside the function body. When we check [136:42] test.prototype, we can see constructor [136:44] function. Prototype is actually nothing [136:46] mysterious. What we're seeing here, that [136:48] is the prototype. So, if someone asks [136:51] you in an interview, what is prototype, [136:53] you can simply say prototype is a [136:54] property of any function in JavaScript [136:56] that points to an object. That is the [136:58] definition of prototype. See what [137:00] happened? We built the concept of [137:02] prototype ourselves through examples. [137:04] Now, let's go a little deeper. Remember [137:06] the earlier object.create example? When [137:08] we use object.create, the child can [137:11] access all parent properties. We don't [137:13] need to assign them separately to the [137:14] child. Our earlier problem was that we [137:16] had to create a separate person methods [137:18] object to keep shared methods. But now [137:20] remember, every function already has a [137:22] prototype object. JavaScript gives us [137:24] this built in. That means inside the [137:26] person function, there is a prototype [137:28] where we can keep shared methods. So, [137:31] what we want to do is instead of [137:32] creating a separate object like person [137:34] methods, use person function's own [137:36] prototype. Keep everything inside the [137:38] person function. Use the built-in [137:40] feature and share methods without a [137:41] separate object. What I will do is I [137:43] copied everything from person methods [137:45] and now person methods is no longer [137:48] needed. So, I removed it. Since we know [137:51] the person function has a prototype [137:52] property, I can write person.prototype [137:55] is equal to a blank object. Then I'll [137:57] put the methods that were in person [137:59] methods into prototype. So, I'll paste [138:01] it in. Just like before, we used [138:03] object.create inside the person [138:04] function. Now, where is person methods? [138:07] We moved it into person.prototype. So, [138:09] instead of person methods in [138:11] object.create, now we will use [138:12] person.prototype. In simple words, we [138:15] just changed the name from person [138:17] methods to person.prototype. And [138:19] person.prototype is the person [138:20] function's own property. So, now we can [138:22] write person is equal to object.create [138:25] and pass person.prototype. Now, what's [138:27] happening? Person.prototype is the [138:29] person function's own property, and we [138:31] are storing the shared methods there. [138:33] So, according to object.create's [138:35] behavior, the child can access all those [138:37] methods. Here, the child is the small [138:39] person object. As a result, when we [138:41] create Messi or Neymar, calls like [138:43] Messi.play or Neymar.play still work. [138:45] That means the improvement we made [138:46] compared to before is we are now using [138:48] prototypes. Like I said, prototype is [138:51] nothing special. It's a built-in [138:52] property of functions that JavaScript [138:54] gives us. In that prototype, we can keep [138:56] the things that need to be shared [138:58] commonly, and the child can access them. [139:00] And yes, we are getting the same output. [139:02] That's fine. The reason I explained the [139:04] story in such a roundabout way is so [139:06] that it's easier for you to remember. [139:08] Maybe after some time, if you practice [139:10] this a few times, prototypes will become [139:11] completely clear. The summary is any [139:14] function has a prototype property. [139:15] Whatever I put in that prototype, the [139:17] child can access it. I could have said [139:19] that in the beginning, but then you [139:21] wouldn't understand the context. You [139:22] wouldn't understand why prototypes are [139:24] needed. Now, you can feel how valuable [139:26] prototypes are. This is why JavaScript [139:28] is called a prototype-based language. [139:30] Prototype is not a new feature. It's not [139:32] some new addition in modern JavaScript. [139:33] Prototypes have existed in JavaScript [139:35] from the very beginning. JavaScript is [139:37] built on prototypes. Built-in languages [139:39] like C or Java, or the languages many of [139:41] us studied academically, there's no such [139:44] prototype concept. Those who have worked [139:46] with class-based languages like C++ or [139:47] Java will understand this easily. Even [139:50] if someone comes from PHP, they know PHP [139:52] now also has classes for object-oriented [139:54] programming. The real thing is classes [139:56] work in a similar way. What we saw in [139:58] the earlier example is basically [140:00] class-like behavior. But JavaScript [140:01] didn't originally have classes by [140:03] default. Vanilla JavaScript had no class [140:05] feature. That's why JavaScript uses [140:07] prototypes, so child objects can inherit [140:10] parent properties. Inheritance means [140:12] just like we get genetic traits from our [140:14] father. In the same way, a child object [140:16] gets traits from a parent object. In [140:18] other languages, this happens through [140:20] classes, but in JavaScript, inheritance [140:22] happens through prototypes. That's [140:24] JavaScript's difference. That's why [140:26] prototypes may sound like a huge topic, [140:28] but prototypes are actually very simple. [140:30] It's a property of JavaScript functions [140:32] that helps with inheritance. Whatever I [140:34] put in prototype, the child object [140:36] inherits all those traits. That's really [140:38] what it is. Look, person. Person is a [140:41] function or object. Whatever traits are [140:43] inside this function's prototype, the [140:44] small person, meaning the child object, [140:47] inherits all those traits from parent [140:49] person.prototype in the same way. In our [140:51] example, there are only methods, but if [140:53] there were other properties, too, the [140:55] child would inherit those as well. [140:56] Everything comes to the child [140:57] automatically. Now, we don't need to [140:59] define any third object, and we don't [141:01] need to create extra things ourself. [141:03] Using built-in prototypes, we can access [141:05] properties from parent to child. If this [141:07] much is clear, then let's go a little [141:09] deeper. The fun starts from here, and [141:11] then you will also understand why I [141:13] explained everything in such a [141:14] roundabout way. From what we have seen [141:16] so far, we learned three things. First, [141:19] how to create a constructor function. [141:20] The person function is called a [141:22] constructor function because through [141:23] this function, we construct an object [141:26] like Messi. There's nothing complicated [141:28] there. By default, all functions in [141:29] JavaScript are constructor functions. We [141:31] can use them easily to create objects. [141:33] The convention for constructor function [141:35] is that the name starts with a capital [141:37] letter. That's why we identify person as [141:39] a constructor function. Second, we [141:41] learned how to add methods to a [141:43] constructor function's prototype. [141:45] Whatever methods we add to person [141:46] constructor's prototype become shared [141:48] across all instances. Third, we learned [141:51] how object.create helps the child [141:53] inherit the parent's properties. These [141:55] are the three things we learned so far. [141:57] And the whole purpose of this process [141:58] was to share common methods among all [142:01] instances of the constructor function. [142:03] Using the person constructor, we can [142:04] create Messi, Neymar, and many more [142:06] person instances. And we went through [142:08] all these steps just to share the common [142:10] methods among those instances. For [142:12] anyone who works with programming, this [142:14] is a very fundamental concept that the [142:16] parent constructor function's properties [142:18] and common methods can be shared with [142:20] the child. This is basic. So, naturally, [142:22] there should be some simple built-in [142:24] shortcut for this. And JavaScript has [142:26] exactly that. What we did earlier, [142:28] creating instances through the person [142:29] function, we can do that using the new [142:32] keyword. For example, in the previous [142:34] code, we created Messi and Neymar like [142:36] this. Messi is equal to person, and we [142:38] passed Messi 38, and same with Neymar. [142:40] Let's comment those out. Now, we write [142:42] it in a new way. Messi is equal to new [142:45] person, and we will pass Messi and 38. [142:48] Same goes with Neymar. So, yes, by [142:50] putting the new keyword before calling [142:52] the person function, we can do the same [142:53] thing. What's happening here? We are [142:55] creating a new person named Messi, whose [142:57] age is 38. Meaning, we passed the [142:59] required data. In simple words, we are [143:02] creating a new person named Messi. So, [143:04] we can say, earlier, we were just [143:06] calling the function, but now, by using [143:08] the new keyword, we are getting some [143:09] extra benefits. I will explain that now. [143:12] Now, let's tweak the example a bit. [143:13] Instead of using the previous person [143:15] function, I'm creating a new function, [143:17] so we have two separate examples, and it [143:19] becomes easier to understand. We are [143:21] changing the function name, so it's [143:22] different from the previous person. Now, [143:24] we will write new person with new and [143:27] pass Messi and 38. And same with Neymar. [143:29] So, we changed the function name from [143:31] person to person with new. Now, we also [143:34] need to create this function body. We [143:36] copied the entire body of the previous [143:38] person function exactly. Just change the [143:40] name. Earlier, it was person. Now, it's [143:43] person with new, because below, we we [143:45] calling person with new. We also copied [143:47] the earlier person.prototype and changed [143:49] it to person with new.prototype. And we [143:51] also used person with new.prototype in [143:53] object.create. I'm doing all this just [143:55] to show you the difference between the [143:57] two because there actually is a [143:58] difference. In the earlier person [144:00] constructor function, we were basically [144:01] doing two things. One, we were creating [144:04] the main object with object.create. [144:06] Without that, the object wouldn't be [144:07] created. And finally, we were returning [144:09] the object so that we could use this [144:11] person object. So, we were doing these [144:13] two things manually. But when you use [144:15] the new keyword, JavaScript [144:16] automatically tries to reduce the [144:18] programmer's work. When using the new [144:19] keyword, we don't need to write separate [144:21] lines for object.create and return [144:23] person. JavaScript assumes those two [144:25] things for you. That means you don't [144:27] have to write those lines manually [144:28] anymore. Is that just convenience? No, [144:31] it doesn't stop there. JavaScript is [144:33] also saying, "Since you don't need to [144:34] write those two lines, let me make this [144:36] even easier." So, JavaScript itself [144:39] internally writes the object.create and [144:41] return lines. I commented out the [144:42] object.create and return person lines. [144:45] Now, think about this. Earlier, I wrote [144:47] object.create and passed [144:48] person.prototype. When JavaScript does [144:50] this internally, it doesn't know or care [144:52] about the variable name person. It won't [144:55] use the name we gave. JavaScript uses [144:57] this instead of person. This, t h i s, [145:00] and it also returns this automatically [145:02] instead of person. That means when we [145:04] used to create let person manually, [145:07] JavaScript now creates it internally as [145:09] this. Just keep this much in mind for [145:11] now. This behaves exactly the same as [145:13] before when we created objects by [145:15] calling normal functions. Back then, we [145:17] had to manually write let person is [145:19] equal to object.create. But when we [145:21] write new person with new, JavaScript [145:24] itself internally writes the let person [145:26] and return person lines. So now, we can [145:28] assume those two lines already exist. We [145:30] only need to assign the properties. [145:32] Those who have worked with React JS [145:33] class components have seen that inside [145:36] constructor functions, we directly use [145:38] this. But we don't manually write [145:39] object.create. JavaScript works the same [145:42] way internally. React also uses this [145:44] internally, and we assign properties [145:46] easily using this. So, now in person [145:48] with new, person.name won't exist. [145:50] JavaScript is basically saying, write it [145:52] using this. this.name is equal to name, [145:55] this.age is equal to age. This is how [145:57] the values will be assigned. So, now [146:00] it's clear that when we create instances [146:02] with new, we don't need to manually [146:04] write Object.create and return [146:05] statement. We can directly assign [146:07] properties using this. And we can also [146:09] add new properties easily. For example, [146:11] we can write this.contact is equal to [146:14] something. So, this way, if we want, we [146:16] can add more properties, too. Now, we [146:18] added a new contact property. Now, [146:20] according to the workflow, we won't keep [146:22] the previous person with new name. We [146:24] will rename person with new back to [146:26] person. We will also change person with [146:28] new.prototype into person.prototype. And [146:31] we'll update all function calls below [146:33] accordingly. We'll just use person [146:35] instead of new person with new. Now, [146:37] let's see if it works. If we do [146:39] messy.play, can we access it? Let's [146:41] check in the console. Similarly, Neymar [146:42] will also work fine. So, this is our [146:45] journey. JavaScript now supports [146:46] classes, too, and prototypes play a very [146:49] important role here. So, now let's [146:51] convert everything we have done so far [146:52] into a complete class. If we use the [146:54] familiar class syntax, we won't have to [146:57] deal with prototypes directly anymore. [146:58] So, let's convert the programs we have [147:00] written so far into a class. To make it [147:02] easier to understand, we'll keep the [147:04] person constructor function at the top [147:06] for now, so you can compare the two side [147:08] by side. We already know person is a [147:10] constructor function. A class also has a [147:12] constructor function. We'll name the [147:14] class person as well. So, we write class [147:16] person. We are using the same name as [147:18] the person function. Inside class [147:20] person, there will be a constructor [147:22] function. This constructor takes two [147:24] parameters, name and age. Inside a [147:26] class, we write the constructor like [147:27] this. Constructor, and pass name and [147:30] age. And inside the constructor, we can [147:32] use this. First, we assign the name [147:34] parameter. So, this.name is equal to [147:36] name. So, the name we receive in the [147:38] constructor is stored in this dot name. [147:41] Then, we add age. This dot age is equal [147:43] to age. With that, the constructor's job [147:45] is done. The functions that were in the [147:47] prototype can now be written directly [147:49] inside the class as methods. We have [147:51] copied all three functions into the [147:52] class. Since those functions had commas [147:54] when they were inside an object or [147:56] prototype, we remove the commas when [147:58] writing them inside the class because [147:59] classes don't use commas between [148:01] methods. That completes our class. Now, [148:03] we can remove the original person [148:05] constructor function and [148:06] person.prototype because we don't need [148:08] them anymore. At this point, we can [148:10] clearly see the comparison, right? [148:12] Finally, we write Messi is equal to new [148:14] person and pass Messi and age as 38. And [148:17] Neymar, same. Then, we call Messi.play [148:20] and Neymar.eat. If you check the output [148:23] in the console, you'll see the exact [148:24] same result as before. Whatever output [148:26] we are getting earlier, we are getting [148:28] the same thing now. So, this is how we [148:30] converted prototype-based code into [148:32] modern class syntax. So, by [148:34] understanding prototypes, we learned a [148:36] lot of things. We saw how objects can be [148:38] created. We learned three ways: with [148:40] functions, with Object.create, and with [148:43] the new keyword. Finally, by coming out [148:45] of prototypes, we were able to transform [148:47] our code into something that looks like [148:49] a complete object-oriented programming [148:51] language style, that is class syntax. [148:54] What we saw so far was the fundamental [148:56] concept of prototypes, how prototypes [148:58] work. Now, I will show you a few [149:00] optional things. You can skip this if [149:02] you want, but I want to show it so you [149:03] can see a real example and feel it more [149:06] clearly. Let's move away from our boring [149:07] example. When we create arrays in [149:09] JavaScript, we usually write persons is [149:11] equal to a blank array. This is actually [149:13] equivalent to let persons is equal to [149:16] new array. Here, new array is the [149:18] constructor, and the third bracket is [149:20] array literal. Because writing new array [149:22] repeatedly is a bit annoying, JavaScript [149:24] gave us array literal syntax for [149:26] convenience. This kind of thing exists [149:28] in many other languages, too. So, yes, [149:30] we usually use third bracket to create [149:32] arrays, but for convenience, let's look [149:34] at new array for a moment. Just like in [149:36] the previous example, we initialized a [149:38] new person using new person. Now, we'll [149:41] do the same kind of initialization with [149:43] array. Now, even before accessing any [149:45] custom property, the array already gives [149:47] us a lot of methods and properties. For [149:50] example, we write persons.push and we'll [149:52] pass Messi. Here, we pushed Messi into [149:55] the array. Then, if we write console.log [149:56] persons, we can see Messi inside the [149:59] array. But, where did the push method [150:01] come from? Because persons is our own [150:03] variable. Persons is a new array. So, [150:05] where is push coming from? Just like in [150:07] the previous person example, we said, [150:09] "Whatever exists in the prototype, the [150:11] child inherits those." In this case, the [150:14] child is persons and the parent is [150:16] capital array. If we write console.dir [150:19] and pass the capital array, then we can [150:21] see a prototype inside it. Now, let's [150:23] inspect that prototype a bit. It will be [150:25] easier to understand. So, let's write [150:27] console.log array.prototype. [150:30] Notice this. We just used push and push [150:32] is right there inside prototype. So, [150:34] that means this exactly matches our [150:36] earlier example. Like I said, whatever [150:38] methods are in the parent's prototype, [150:40] the child can access them. That's [150:42] exactly what's happening here, too. [150:43] Capital array is the parent and the [150:45] methods are in its prototype. That's why [150:48] the child can access those methods. [150:49] Through this example, I wanted to show [150:51] how prototypes work in a real built-in [150:53] example. I hope this made it much [150:55] clearer. Many times when you work, we [150:57] just think of this as built-in features. [150:59] Like array.push just works because [151:01] JavaScript understands it. But, why does [151:03] it work? It works because of prototypes. [151:06] When we create any object, it inherits [151:08] the properties and methods that exist in [151:10] its parent's prototype and all of those [151:12] become accessible to the child as well. [151:14] This is actually called a prototype [151:16] chain. Chain is a very simple idea. [151:17] Whether we write new array or create a [151:19] new object, the same idea is working [151:22] underneath. If you understand prototypes [151:23] properly, then you can really reach boss [151:26] level in JavaScript. [151:30] In today's video, I'm going to talk to [151:32] you about object-oriented programming. [151:34] When JavaScript developers hear the term [151:36] object-oriented, they suddenly feel sick [151:39] like something very complicated. Some [151:41] even get scared of it. But honestly, [151:44] it's not that difficult. My main goal in [151:47] this video is to explain object-oriented [151:49] programming in such a way that even a [151:51] beginner or even a young kid can [151:54] understand it easily and get a [151:56] completely clear idea about it. So, [151:59] without wasting any more time, let's get [152:01] started. Let's get straight to the [152:03] point. What exactly is object-oriented [152:05] programming or OOP in short? As humans, [152:08] we naturally think of everything around [152:10] us as objects. But when it comes to [152:13] writing code, we often forget to look at [152:15] it that way. Especially, those of us who [152:18] are using scripting languages like [152:20] JavaScript or Python tend to think in a [152:23] functional style. Meaning, we try to [152:25] solve everything through small, separate [152:27] functions. That's because these [152:29] languages were originally designed with [152:32] a stronger tilt toward functional [152:34] programming. But that doesn't mean [152:36] object-oriented concepts don't work [152:38] here. If we want, we can absolutely [152:40] apply object-oriented principles in [152:42] JavaScript or Python as well. But if we [152:45] look at some popular programming [152:47] languages like Java or C++, these were [152:50] specially designed with object-oriented [152:53] programming in mind. However, even in [152:55] languages like JavaScript and Python, [152:57] you can still make use of [152:59] object-oriented concepts if you want. [153:01] Let's understand this with a simple [153:03] example. Suppose you need to build a [153:06] soccer game. The game will have [153:08] different players. Now, if you want to [153:10] define a football player in code, in [153:13] JavaScript, you can create an object [153:15] that contains properties like name, age, [153:18] and skill. If there's only one player, [153:21] say Ronaldo, then it's not a problem. [153:23] You can easily represent him with a [153:25] simple object. But, when you need [153:27] multiple players like Ronaldo, Messi, [153:30] Neymar, you would have to define each [153:33] one as a separate object. And that's [153:35] where a big problem appears. All three [153:37] players share almost the same object [153:40] structure. Yet, you are writing them out [153:42] separately. If that number grows, say [153:45] 100, 200, or even 300, you'd be manually [153:49] writing each one every single time. The [153:52] first problem is you end up writing [153:55] duplicate code. When you repeat the same [153:57] thing over and over, the chances of [153:59] mistakes go up. [154:00] For example, while creating Ronaldo's [154:03] object, if you accidentally type s i k w [154:06] l instead of s k i w l, it can be hard [154:10] to catch. As you write hundreds of such [154:12] objects, these kind of errors will [154:15] increase and introduce unnecessary bugs [154:17] into the code. This is exactly where [154:20] object-oriented solves the problem. [154:23] Now, imagine someone suddenly tells you [154:25] to add a new property to the player [154:27] object. Let's say experience. If your [154:30] code already has a hundred player [154:32] objects, you'd have to find all hundred [154:35] and add the experiences property to each [154:37] one manually. That's obviously tedious [154:40] and time-consuming. And that's a major [154:43] issue. These are exactly the kinds of [154:45] problem object-oriented programming was [154:47] created to solve. If we had thought in [154:50] an object-oriented way from the [154:51] beginning, we wouldn't face this hassle [154:54] because there's one common factor here. [154:57] They're all soccer players. Ronaldo, [154:59] Messi, or Neymar. They may be different [155:02] individuals, but their core identity is [155:05] the same. They are all soccer players. [155:07] That means there should be a generic or [155:10] common structure for all of them. And [155:13] from that structure, each one will be [155:15] created individually. And this common [155:17] structure is what we call a class. The [155:20] foundation of object-oriented [155:22] programming is actually built on this [155:24] very concept of classes. So, as we just [155:27] saw, when creating individual objects, [155:30] the properties of each one are basically [155:33] the same. Now, if we want to bring all [155:35] of that into a common place, we will [155:38] need something like a factory, a system [155:41] from which all players will be created. [155:43] Imagine we have a player factory. All we [155:46] will do is provide that data. For [155:48] example, Ronaldo, age 35, skill striker, [155:53] experience 10 years. For Messi, the [155:56] name, age, and skill will be different, [155:58] but the properties will still remain the [156:00] same. In other words, even though the [156:02] data is different, the structure or [156:05] characteristics remain the same. And [156:07] this is exactly what the concept of a [156:09] class comes from. A class is the [156:12] blueprint or design from which objects [156:15] are created. For example, suppose we [156:18] create a class called player. Inside [156:20] this class, we will have common [156:22] properties like name, age, and skill, [156:25] but it won't contain the details of any [156:28] individual player. It will only define [156:30] the structure. Then, using this [156:33] blueprint, we can create Ronaldo, Messi, [156:36] or Neymar whenever we want. So, what [156:39] exactly is a class? A class is basically [156:41] a common structure or a factory where [156:44] all the properties are predefined. And [156:47] when we write new player, a new player [156:50] is created using that blueprint. For [156:52] example, if we write new player, it will [156:55] create a new object where the name will [156:57] be Ronaldo, the age will be 35, and the [157:00] skill will be striker. Notice one thing [157:03] here. The player class itself is not [157:06] Ronaldo. Instead, it's the common [157:08] structure from which many players like [157:10] Ronaldo, Messi, or Neymar can be [157:12] created. And only when we call new [157:15] player, that's when the actual Ronaldo [157:18] object is created. This way, our code [157:21] becomes much cleaner and easier to read. [157:24] Now, imagine we need to create hundreds [157:26] of players like before. We no longer [157:28] have to write duplicate objects over and [157:30] over. All we need to do is call new [157:33] player. And a new player will be created [157:36] instantly. And if there's ever a bug, it [157:39] will be much easier to find because all [157:41] the properties are defined in one place, [157:44] inside the player class. Now, let's talk [157:47] about the constructor. [157:49] When we write new player in the bracket, [157:52] Ronaldo, {comma} 35, {comma} striker, [157:56] the arguments we're passing here are [157:58] actually the arguments of the [157:59] constructor function. A constructor is a [158:02] special function that lives inside a [158:04] class, and it gets called automatically [158:07] whenever a new object is created. That [158:09] means whenever we use new player, [158:12] JavaScript automatically calls the [158:14] classes constructor function. And the [158:16] arguments we pass in, like Ronaldo, uh [158:19] 35, striker, get assigned inside the [158:22] constructor to this.name, this.age, and [158:25] this.skill. So, later, we can easily [158:28] access them as Ronaldo.name, [158:30] Ronaldo.age, or Ronaldo.skill. [158:32] Simply put, a class is the blueprint, [158:35] and the constructor is the machine that [158:38] builds the actual object from that [158:40] blueprint. When we call new player, the [158:43] arguments we pass go directly into the [158:45] constructor function inside the class. [158:47] For example, if we call new player, [158:50] Ronaldo, 35, striker, these three [158:53] values, Ronaldo, 35, and striker, are [158:56] passed as parameters to the constructor [158:58] function, which in this case is [158:59] expecting name, age, and skill. So, what [159:02] does the constructor do? It takes those [159:04] arguments and initializes them inside [159:07] the object. Meaning, it sets them using [159:09] this.name is equal to name, this.age is [159:12] equal to age, and this.skill is equal to [159:15] skill. Here, this actually refers to the [159:18] object that's been created at that [159:20] moment. For example, if we call new [159:23] player with Ronaldo, 35, and striker, [159:26] then this refers to the Ronaldo object. [159:29] If we call new player Messi, 36, and [159:33] striker inside the same constructor [159:35] function, this will now refer to the [159:38] Messi object. In other words, this is a [159:40] generic reference that always represents [159:43] the specific instance being created at [159:46] that moment. To put it more simply, this [159:49] works like a nickname. Just as you might [159:51] call your child by different names, [159:54] baby, sweetie, or cutie, no matter which [159:57] name you use, you are still referring to [160:00] the same child. In the same way, this is [160:03] a reference that always points to the [160:05] specific object being created each time [160:08] a new instance is being made. [160:10] So, the whole process works like this. [160:13] Number one, you write new player [160:15] Ronaldo, 35, striker. Number two, the [160:19] constructor is called automatically. And [160:21] number three, the constructor takes the [160:24] arguments and sets them to the [160:26] properties of this object. And finally, [160:29] number four, a new object is created, [160:32] which gets stored in the Ronaldo [160:33] variable. [160:35] Now, when you call Ronaldo.name, you [160:37] will get Ronaldo. If you call [160:39] Ronaldo.age, you will get 35. And [160:42] calling Ronaldo.skill will return [160:44] striker. This is how the constructor [160:47] works automatically whenever we use new [160:50] to create an object from a class. And [160:53] this newly created object is called an [160:55] instance. That means Ronaldo is an [160:58] instance or the real form of the player [161:01] class. In the same way, you can create [161:03] as many instances as you want. Messi, [161:06] Neymar, Ramos, each will be a separate [161:09] instance of the player class. So far, we [161:12] have seen how the default constructor [161:14] method of a class works, but it doesn't [161:17] stop at the constructor. You can also [161:20] write your own custom functions inside a [161:22] class. When a function is written inside [161:25] a class, it's called a method. It works [161:28] just like a normal function, but since [161:31] it lives inside a class, it gets a [161:33] special name, method. For example, let's [161:36] say we add a method called say hello. [161:39] Now, when you create an instance with [161:42] new player Messi 35 and striker, along [161:46] with the name, age, and skill set inside [161:49] the constructor, this new say hello [161:52] method will also be available in that [161:54] object. So, you can directly call [161:57] Messi.sayHello. [161:59] Since Messi is the main object or [162:01] instance, you will be able to access [162:03] that method through it. [162:06] And when you call it, you will get a [162:07] nice output in the console, like "Hello, [162:10] my name is Messi and I'm a striker." In [162:13] other words, methods represent the [162:15] actions or behaviors of an object. For [162:18] example, a player object's properties [162:21] like name, age, and skill define its [162:23] characteristics, while a method like say [162:26] hello defines its behavior or how it [162:29] acts. You can add multiple methods if [162:32] you want, such as play, retire, or show [162:35] stats. This way, object-oriented [162:38] programming doesn't just keep an object [162:40] limited to storing data. It also gives [162:43] the object the ability to perform [162:45] actions. I hope this made sense. So, [162:48] let's keep one thing clear from the very [162:51] beginning. A class is basically the [162:53] design or blueprint of of object. Thanks [162:56] to this blueprint, we can avoid writing [162:58] duplicate code, reduce the amount of [163:00] code we need, and if we ever want to add [163:03] a new property or characteristic in the [163:05] future, we can do it in just one place. [163:08] That's why OOP is considered elegant, [163:11] and it's widely used in building [163:13] large-scale software. This is the basic [163:15] idea. Now, let's look at an example. [163:18] Suppose your game has a class called [163:20] human. Inside it, there's a constructor [163:23] that will only take a name when creating [163:25] an object from outside. [163:27] Every human has two hands and two legs. [163:31] These are fixed and are same for [163:33] everyone. So, they can be treated as a [163:35] static properties, and the name will [163:37] come from outside when the object is [163:40] created. Now, you will notice that just [163:42] the human class isn't enough because in [163:46] your game, there are different types [163:48] based on age, like baby and teenager. If [163:51] you define a baby class, it will also [163:54] have a name, two hands, and two legs [163:56] just like a human, but it will also have [163:59] its own unique property. Let's say a [164:01] baby is very cute. That can be stored as [164:04] a separate property. Along with that, a [164:07] baby will have its own method, cry, [164:10] since babies cry. [164:12] In the same way, you have another class [164:14] called teenager. Just like before, it [164:16] has the same three common things, name, [164:19] arms, and legs. These three actually [164:21] come from the human class, but a [164:23] teenager also has unique [164:26] characteristics. For instance, being [164:28] emotional, and because of that, [164:30] teenagers often show a distinct [164:32] behavior, like getting a crush when they [164:35] see someone attractive. We can define [164:37] that as its own method. Now, if you look [164:40] closely, both the baby class and the [164:42] teenager class have name, arms, and [164:45] legs. That means the same code is being [164:48] duplicated. To To this kind of [164:51] repetition, object-oriented programming [164:53] uses a special concept called [164:55] inheritance. The word inheritance means [164:58] receiving something naturally from [165:00] ancestors or parents. Just like in real [165:03] life, you inherit many traits from your [165:05] parents. For example, if your parents [165:07] are very intelligent, you likely [165:09] inherited that to some extent. Or let's [165:12] say your father is tall or short, you [165:15] inherit that physical trait through DNA. [165:18] In the same way, in programming, a child [165:21] class automatically inherits the common [165:23] properties and methods of its parent [165:25] class. So, now let's put that concept [165:28] into practice. [165:30] Suppose your main class is named human, [165:33] and then you create another class called [165:35] baby. To quickly build baby from human, [165:38] we write class baby extends human. [165:43] Here, extends is a keyword that allows [165:45] the baby class to inherit from the human [165:47] class. This means whatever features the [165:50] human class has, the baby class [165:52] automatically gets them, too. That's how [165:54] inheritance works in code by using [165:57] extends. So, when baby extends human, it [166:00] inherits all the common properties like [166:03] name, arms, and legs. On top of that, [166:06] baby adds its own unique property, which [166:08] is this.cute. Exactly, the baby class [166:11] also has its own special method called [166:13] cry. This is how one class can take [166:16] properties from another and form a new [166:19] one. And this whole process is what we [166:21] call inheritance. In the same way, the [166:24] teenager class will work just like this. [166:27] It will inherit the common features from [166:29] human, but it will also have its own [166:31] unique property, emotional. [166:33] And its own method, crash. [166:36] I hope this part is clear now. [166:39] Now, let's move on and see how to [166:41] actually call or create these objects. [166:44] So, we have baby class, and it's [166:46] extended to human class. Now, when you [166:49] want to create a new baby object, you [166:51] might write const Monty is equal to new [166:56] baby Monty. This would create a new baby [166:59] object and set its name to Monty. [167:01] But be careful. Written like this, the [167:04] code won't work straight away. The [167:06] reason is inside the baby class, we [167:09] never initialized this.name, but the [167:11] name property has originally defined in [167:14] the human class. When we create a new [167:16] object, only the baby class constructor [167:19] is called automatically, not the human [167:22] classes constructor. So, how will the [167:24] human class know that the name passed [167:27] into baby's constructor should also be [167:29] set as the parent human's name? [167:32] To solve this, we need to call the [167:34] parent classes constructor from the baby [167:37] classes constructor. And for that, we [167:40] use super method. [167:42] Whenever you write super name inside the [167:45] baby classes constructor, that name [167:48] value gets passed to the human classes [167:50] constructor. And human takes care of [167:52] initializing it properly. Exactly, [167:55] that's the point. From the child class, [167:57] if you want to send values to the parent [167:59] classes constructor, you have to use [168:01] super method. Without it, the parent [168:04] class would never know that it needs to [168:06] receive the value for name. So, what you [168:09] need to do is simple. Just call the [168:11] super method. For example, when you call [168:14] new baby Monty, the string Monty first [168:17] comes into the baby classes constructor. [168:20] Now, since baby's parent is human, that [168:23] name parameter must be passed up to [168:26] human. Otherwise, the this.name, [168:29] this.arms, and this.legs inside human [168:32] won't get initialized. To fix that, we [168:35] call super in the bracket name. [168:39] When you place super name right above [168:42] this.cry in baby's constructor, what [168:44] actually happens is the human class's [168:47] constructor gets called, and it takes [168:49] care of initializing those parent [168:51] properties properly. So, I hope I have [168:54] been able to give you a clear idea about [168:57] inheritance. Object-oriented programming [168:59] has many more ideas beyond this. For [169:01] example, apart from the methods we have [169:03] looked at, there are also static [169:05] methods, private methods, and private [169:08] properties. Not only that, OOP is built [169:11] on four main pillars. I only discussed [169:14] inheritance here, but there are also [169:16] abstraction, polymorphism, and other [169:18] important concepts. If you would like me [169:21] to cover those in detail, and if you [169:22] feel this tutorial helped you understand [169:25] things easily, then do let me know in [169:27] the comments and request more videos. [169:29] Also, share how you found this video. If [169:32] you enjoyed it, don't forget to like and [169:34] share. If I get good responses from you, [169:37] I will keep making more videos like [169:39] this. I hope this video has been useful [169:41] for you. Thank you, everyone. [169:46] Today, I'm super excited to share [169:48] another important JavaScript concept [169:50] with you, event propagation technique. [169:52] We will dive into event bubbling and [169:54] event capturing. Earlier, I made a video [169:56] on event delegation, which is actually a [169:59] part of event propagation. That topic [170:01] needed a separate video, so you will [170:03] find the link to that in this video [170:05] description. By the end of this video, [170:07] you will understand how bubbling and [170:09] capturing work, and be ready to tackle [170:11] some tricky interview questions related [170:14] to them. Let's get started. Let's begin [170:16] with a simple example. First, what is [170:18] event propagation? The word propagation [170:21] means spreading or moving from one place [170:23] to another. It comes from the English [170:25] verb propagate, and propagation is the [170:28] noun form. Simply put, it's about moving [170:30] up, down, or spreading along a specific [170:33] path. We already know how events work in [170:36] JavaScript, but the question is, in what [170:39] order do these events run? That whole [170:41] process is called event propagation. To [170:44] make it clearer, let's look at the [170:46] example in the browser. You can see a [170:48] button inside a form, and that form is [170:50] inside a parent div. The green part you [170:52] see is the form, and the purple border [170:54] around it is the parent div. If you look [170:57] at the index.html for this example, you [170:59] will see there's a div, the parent, [171:01] inside it a form, and inside the form [171:04] there is a button. The styles you see [171:06] are coming from a style.css file. I will [171:09] share the code on GitHub, so you can [171:10] check it out if you want. That's our [171:12] current setup. Now, if we add separate [171:15] event listeners to each of these three [171:16] elements, one for the button, one for [171:19] the form, and one for the parent div, [171:21] when you click the button, the event [171:23] should fire in all three places, right? [171:25] Because the button is inside the form, [171:27] and the form is inside the parent div. [171:30] So, which order do the event listeners [171:32] run in? Does it go from child to parent [171:34] or the other way, from parent to child? [171:37] This whole process is called event [171:39] propagation. In other words, the order [171:41] in which events run is what we call [171:44] event propagation. That's the main [171:46] definition. Event propagation has three [171:48] parts: event bubbling, event capturing, [171:51] and event delegation. I have already [171:53] made a video about event delegation, and [171:55] you will find the link in the video [171:56] description. Today, we'll dive into [171:58] bubbling and capturing. [172:00] Let's say our script.js file is attached [172:03] to index.html. In script.js, I have [172:06] selected the three elements, the parent [172:08] div, the form, and the button, using [172:10] document.getElementByID. [172:13] Each has a click event listener [172:14] function, and all of them use a common [172:16] function as the listener. So, when you [172:19] click the click here button, you will [172:20] see do something logged three times in [172:23] the console. Now, which output comes [172:26] first and which comes later? To figure [172:28] this out, you could use separate [172:30] listeners. But, since we are using a [172:32] common function, we need to use the [172:34] event object. Inside the event object, [172:37] there's event.target property, which [172:39] tells us which element was actually [172:42] clicked. So, console.log event.target [172:46] lets us know the real target element. If [172:48] you watched the previous event [172:50] delegation video, you will understand [172:51] this part even better. There, we saw [172:54] that event.target gives us the HTML [172:57] element that was targeted. Now, if we [172:59] refresh the browser and click the click [173:01] here button, you will see the button [173:03] element logged three times. That's [173:05] natural, because target means where the [173:08] click happened. Since you clicked the [173:10] button, it shows the button each time. [173:13] But, the interesting thing is when you [173:14] click, not only the button's listener [173:16] fires, but also the form's and the [173:19] parent div's listeners fires, also. Yet, [173:22] the target is always the button in all [173:25] three cases. So, the output looks the [173:27] same. [173:28] If you want to know which listeners are [173:30] being called, you need to use [173:31] event.currentTarget. [173:34] Now, if you click the button again, you [173:36] will see first the button, then the [173:38] form, and the parent div. So, the event [173:41] is moving from child to parent. Since we [173:44] didn't configure anything, the events [173:46] are running in their default behavior, [173:48] moving from child to parent. First the [173:50] button, then the form, then the parent. [173:52] This default order is called event [173:54] bubbling. What does bubbling means? The [173:57] word comes from bubbles. Think about [173:59] what happens when you blow soap bubbles. [174:02] They rise from the bottom to the top. In [174:04] the same way, events move upward. That's [174:06] why it's called event bubbling, right? [174:09] Now, we clearly see that event.target [174:12] and event.current target aren't the [174:14] same. This is a common interview [174:16] question. For example, if you don't use [174:18] event.current target and just log this [174:21] in the console, what happens? Let's [174:24] check. See, this actually returns the [174:26] same element. So, inside an event [174:29] listener, this refers to current target. [174:32] That means this is equal to current [174:35] target. Let's understand what current [174:37] target means. Current means the one [174:40] that's active at the moment. For [174:42] example, when you click the button, the [174:44] main target is the button. So, in all [174:46] three cases, target is the button. But [174:49] current target changes step by step. In [174:51] the bubbling process, the event is first [174:53] on the button. So, current target is the [174:56] button. Then, when the event propagates [174:58] to the form, current target becomes the [175:00] form. Finally, when it reaches the [175:02] parent, current target is the parent [175:04] div. This current target is what you get [175:06] as this inside the event listener. So, [175:09] if you get asked in an interview, you [175:11] can simply answer this and [175:13] event.currentTarget do the same thing. [175:15] You can even get different information [175:17] from current target. For example, [175:19] current target.className gives you the [175:22] class and this.tagName gives you the tag [175:25] name. So, when you click the button, the [175:27] output will be button, then form, and [175:30] then div, just like in our markup. Isn't [175:34] that cool? [175:35] Now, we clearly understand how [175:37] event.currentTarget, [175:39] event.target, and this work together, [175:42] even though they are different. We have [175:44] also got a good grasp of bubbling [175:46] process. So, that's great. Let's see [175:49] what happens if we want to reverse the [175:51] default bubbling flow. By default, the [175:53] event goes from bottom to top. But what [175:55] if we want it to go from top to bottom? [175:58] It's simple. You need to use the third [176:00] parameter in the event listener. In this [176:02] third parameter, you can pass an object [176:05] with a property called capture. By [176:07] default, capture is false. If you want [176:09] the event to go from top to bottom, set [176:12] capture to true. [176:14] Now, when you click the button in the [176:15] browser, you'll see the parent div fires [176:18] first, then the form, then the button. [176:21] So, the default order is reversed. This [176:24] process is called event capturing or [176:26] trickling. It's the opposite of [176:28] bubbling. So, we have seen two types of [176:31] propagation, default bubbling and [176:33] capturing or trickling. That's also [176:36] event delegation, which I have already [176:38] shown in a previous video. [176:40] Finally, here's a fun fact for job [176:42] interviews. Sometimes, the order of your [176:44] events can be random. Suppose you have a [176:47] requirement and you have removed the [176:49] third parameter. In the interview, you [176:51] are told when you click the button, the [176:53] form's listener should fire first, [176:55] meaning the button's immediate parent [176:57] comes first, then the button's listener, [177:00] and finally the parent div's listener. [177:02] You might think by default bubbling [177:03] means the button fires first, then the [177:05] form, then the parent. But here, they [177:08] want the form first, then the button, [177:10] then the parent. So, what should you do? [177:13] Remember, if you set capture to true on [177:15] all elements, then by default capturing [177:18] will make the parent fire first, then [177:20] the form, then the button. But we want [177:22] the form first, button second, and [177:24] parent at last. So, setting capture to [177:28] true on all won't work. You need to [177:30] think step-by-step. Set capture to true [177:33] only on the form's listener. Keep [177:36] capture false on the button's listener [177:38] and also keep capture false on the [177:40] parent's listener. If you set it up this [177:42] way, the form fires first, then the [177:44] button, then the parent. Got it? The key [177:48] is to bring the button's immediate [177:50] parent into the capturing method and [177:52] keep the parent div in normal bubbling. [177:54] So, just set capture to true on the [177:56] form's listener. [177:58] Understand that by default, when you [178:00] click the button, the button fires [178:02] first, then the form, then the parent. [178:04] But if you set capture to true on the [178:06] form's listener, the event fires on the [178:08] form first, then the button, and the [178:11] parent div's listener fires according to [178:13] bubbling. So, first the form, then the [178:15] button, then the parent. Choose the [178:18] order you want. Because capturing is [178:20] applied only to the form and not to the [178:22] parent. So, the parent follows bubbling. [178:25] This is a question that often comes in [178:27] interviews in different ways. But if you [178:29] know the step-by-step process and fully [178:31] understand bubbling and capturing, you [178:33] won't have any trouble. I hope this [178:36] example helped you see how it works. [178:38] Here's a final trick. Sometimes there's [178:41] a shortcut for the third parameter. [178:43] Instead of passing an object, you can [178:44] just write true. By default, it's false. [178:47] If you only want to set capture to true, [178:50] just use true directly. But if you want [178:52] to set more options, then use an object. [178:55] You can check the documentation for all [178:57] the options. To sum up, today we learned [179:00] about event propagation and its [179:02] techniques. Bubbling, capturing, also [179:04] called trickling, current target, this [179:07] keyword, you now know all of this [179:09] clearly. I hope this video was helpful [179:11] for you. If you get asked in a job [179:13] interview, what is event propagation? [179:15] What is event capture? What is event [179:17] bubbling? What is trickling? What is [179:20] current target? What is this? You will [179:22] be able to answer confidently. If you [179:25] enjoyed this video, don't forget to hit [179:26] the like button. Drop a comment to let [179:28] me know your thoughts and share it with [179:30] your friends so they can get benefited [179:31] too. It really helps me bring you more [179:33] value-packed tutorials. Thanks for [179:35] watching and I will see you in the next [179:37] one. [179:40] Today, I'm super excited to share an [179:42] important JavaScript concept with you. [179:44] Event delegation. This is a topic that [179:46] often comes up in job interviews. The [179:49] name might sound a bit complicated, but [179:51] once you see the implementation, you [179:52] will realize how simple it actually is. [179:55] By the end of this video, you will be [179:57] confident enough to explain event [179:59] delegation clearly in any job [180:01] interviews. So, let's get started. Let's [180:03] begin with a simple example. The word [180:05] delegation means to assign your task to [180:08] someone else. That's where the idea of [180:10] event delegation comes from. In [180:12] JavaScript, we know about events and [180:14] event listeners. For example, when you [180:16] click on an element, we can catch that [180:18] event with an event listener and respond [180:20] accordingly, right? We all know this. [180:23] So, what exactly is event delegation? [180:26] Normally, we attach an event listener to [180:28] a single element and perform actions [180:30] based on its events. But, the real [180:32] meaning of delegation is using just one [180:35] event listener for multiple elements. [180:37] Imagine you want something to happen [180:39] when you click on this JavaScript [180:41] element and something else when you [180:42] click on this PHP element. To do this, [180:45] you would usually add separate event [180:47] listeners to each element. If you have [180:49] five elements, you would need five [180:51] different listeners. And event [180:53] delegation is useful in situations like [180:55] this. Suppose your list data comes from [180:57] an API or you don't know how many list [181:00] item you will have. Maybe you have a [181:02] button that adds new elements to the [181:04] list when clicked. In these cases, you [181:06] would need to create event listeners [181:08] dynamically, right? That's where event [181:10] delegation comes in handy. There are two [181:12] main things to understand here. First, [181:14] we use a single event listener for [181:16] multiple similar elements. And the [181:18] second is, even if new elements are [181:20] added dynamically to the list, that same [181:22] single event listener will still work. [181:25] Let's see these two concepts in code. [181:27] Here's the HTML page we'll be working [181:29] with. There's already a script.js file [181:31] created and we will write our code [181:33] there. Looking at the UI, the list you [181:35] see is an unordered list or UL. If we [181:38] were to add event listeners to each LI [181:40] item separately, what would we do? We [181:43] would give each LI a unique identifier [181:45] and add an event listener to each one, [181:47] ending up with five separate event [181:49] listeners. But, we are not going to do [181:51] that. Instead, we will use just one [181:54] event listener. Simply put, we will [181:56] apply the event listener to the parent [181:58] element of the list, not to each item [182:00] individually. So, what's the parent [182:02] here? It's the UL element. I I given the [182:05] UL an ID of list. So, we can select it [182:08] using document.getElementById [182:10] list. After selecting it, our next step [182:13] is to add an event listener to this [182:15] list. Let's listen for click events. In [182:18] the callback function, we'll get the [182:19] event object. For now, I'm showing that [182:22] event in the console using console.dir. [182:25] So, we can see what's inside. Please [182:27] note that I'm using console.dir in place [182:30] of regular console.log for more detailed [182:32] login. Save the script.js, open the [182:35] browser console, and click anywhere on [182:37] the UL list. You'll see a pointer event [182:40] object with lots of information. If you [182:42] look closely, you'll find out which HTML [182:45] element was clicked inside the target [182:47] property. This means when you hover over [182:49] the target property in the UI, that [182:51] element gets highlighted. So, no matter [182:54] which LI you click, you'll get the same [182:56] kind of output. In other words, [182:58] event.target contains the actual HTML [183:01] element, in our case, the LI, right? If [183:04] we change some styles, say, set the [183:06] background color to yellow, it will [183:08] apply directly to the LI. Now, if you go [183:11] to the browser and click any LI in the [183:13] list, you'll see exactly that happening. [183:15] This is how we have implemented event [183:17] delegation. We didn't work on each LI [183:20] item individually. Instead, we added the [183:22] event listener to the parent element, [183:24] delegating the responsibility to the [183:26] parent. That's event delegation. So, the [183:29] first condition of event delegation is [183:31] fulfilled. We are using just one event [183:33] listener. Now, let me mention something [183:36] else. Suppose you want to perform [183:38] different actions on individual [183:40] elements, not just the same thing for [183:42] all. Yes, that's possible. You can do [183:45] different things based on the target. [183:47] Inside the event listener, we are using [183:50] console.dir in the bracket e.target. [183:53] That lets us see which element was [183:56] actually clicked. If you move your mouse [183:58] over the UL, you will see the whole area [184:01] highlighted in green showing the parent [184:03] area. [184:04] So, if you click anywhere on the UL, the [184:06] whole area turns yellow. But, we want [184:09] the event to happen only when an LI is [184:12] clicked. Simply put, we can check the [184:14] target. If it's an LI element, the code [184:17] will run, otherwise nothing happens. [184:20] It's easy to do an if else check inside [184:23] the event listener. What should we [184:24] check? For example, we can write [184:26] e.target.matches [184:28] function in the if statement. If you [184:30] don't know about the matches function, [184:32] let me explain the matches concept. You [184:34] can use the matches function on any HTML [184:37] DOM element. element.matches returns [184:40] true or false, meaning it checks if the [184:43] element matches the given selector. For [184:45] example, if we write e.target.matches [184:48] and in the bracket LI, the code will run [184:51] only if it matches an LI item. You can [184:54] use any CSS selector in the matches [184:56] function, a class, ID, or element type. [184:59] Whatever you provide, the function works [185:01] accordingly. [185:03] Now, if you go to the browser, you will [185:04] see that clicking on the empty part of [185:06] the UL doesn't trigger the event [185:08] anymore. Only clicking on an LI triggers [185:11] the code. So, you have got a level of [185:13] control. Now, let's say you want to give [185:15] different colors to each element, not [185:17] just the same color for all. For [185:19] example, you want JavaScript to be [185:21] yellow, PHP to be red, Java to be blue, [185:24] and Python to have another color. That's [185:26] easy to do. We only need the text inside [185:29] each list item. [185:30] To get that, we can simply use [185:32] console.dir [185:34] e.target in the bracket again. [185:37] When we click on any LI, check the [185:39] console. You will notice an inner text [185:41] property. [185:42] That property holds the text of the LI [185:44] you just clicked. For example, if the [185:47] LI's text is JavaScript, you can act [185:49] accordingly. It's easy to do this in [185:51] code. Just add a simple check inside the [185:54] event listener. You can use a switch [185:56] case or individual if else elements. [185:58] Whatever logic you use, let's say you [186:00] check e.target.innerText. [186:03] If inner text is equal to JavaScript, [186:05] set the background color to yellow. For [186:07] any other element, set it to blue. So, [186:09] if you click on the JavaScript li, it [186:12] turns yellow. Clicking on any other li [186:14] turns it blue. Now you have control. You [186:17] can implement any logic you want, but [186:20] the main thing is by putting the work on [186:22] the parent element, you have delegated [186:24] the responsibility. That's why it's [186:26] called event delegation. The second [186:28] condition of event delegation is that [186:30] the listener works even when new [186:32] elements are added. Now, let's add a new [186:35] element. Suppose, below the ul, we add a [186:37] div and a button. The button says add [186:40] new element and calls the add element [186:42] function on click. We haven't created [186:45] the add element function yet, so let's [186:47] do that now. In script.js, we need to [186:50] create a function called add element. [186:52] Inside this function, we will [186:53] dynamically add a new element. That's [186:55] easy to do. For example, we'll write new [186:58] element is equal to [186:59] document.createElement, [187:02] a standard DOM method for creating new [187:04] elements. Now, we have created a new [187:07] HTML element, say an li. Then we set its [187:10] text with new element.textContent [187:12] is equal to Ruby. Next, we need to add [187:15] this new element to our list. That's [187:17] done with list.appendChild and in the [187:20] bracket new element, which adds a new [187:22] child to the end of the list. Now, if [187:24] you look at the browser, you will see a [187:26] new li called Ruby added to the UI. If [187:29] you click on Ruby, you will see that the [187:31] event listener is working still. This [187:33] confirms that our event delegation is [187:35] fully effective. From this, you can see [187:38] that both conditions of event [187:39] delegations are met. First, we are using [187:42] a single event listener for multiple [187:44] elements. Second, the listener works [187:46] even when new elements are added, [187:48] whether from an API or dynamically. If [187:50] we had added separate listeners to [187:52] individual elements, we would have to [187:54] create new listeners every time a new [187:56] element was added. But now, we have [187:58] added one listener for the whole list, [188:01] and it's working. [188:02] That's a big advantage. You can control [188:05] the entire list from a single place. [188:07] That's the end of event delegation. I [188:09] hope you will never be surprised if you [188:11] are asked about it in a job interview. [188:13] You will be able to explain what event [188:15] delegation is and how it works [188:17] confidently. If you enjoyed this video, [188:19] don't forget to hit the like button, [188:21] drop a comment to let me know your [188:22] thoughts, and share it with your friends [188:25] so they can get the benefit, too. Let me [188:27] quickly mention our Logic Based Labs [188:29] Facebook and LinkedIn pages. That's [188:31] where we regularly share coding cheat [188:33] sheets, design system guidelines, and [188:35] tons of developer-focused content. If [188:37] you want that kind of rich, practical [188:39] value in your feed, go follow the page. [188:42] You will find all the links, GitHub, [188:44] Facebook, LinkedIn, everything, right [188:47] there in the video description. [188:49] Thanks for watching, and I'll see you in [188:50] the next one. [188:55] JavaScript was once called the most ugly [188:57] language, but it has evolved [188:58] significantly over time thanks to a rich [189:01] and resourceful ecosystem. It is now [189:03] considered the most popular programming [189:04] language. Some even say it will eat the [189:07] entire internet. But today, we aren't [189:09] just here to praise it. The most [189:11] important factor that transformed [189:13] JavaScript into the powerhouse it is [189:15] today is its asynchronous behavior. To [189:18] work with JavaScript at an advanced [189:19] level, you first need to understand this [189:21] concept. In this video, I'll give you a [189:24] clear idea of how asynchronous [189:26] JavaScript works, so that you won't have [189:28] any more confusion. [189:34] By nature, JavaScript cannot perform [189:36] multiple tasks at once. It runs one [189:38] operation at a time, which is why it's [189:41] called a single-threaded programming [189:42] language. What does that actually mean? [189:45] Let's imagine a restaurant scenario. [189:47] Suppose a restaurant has two tables and [189:49] one waiter. The waiter goes to table [189:51] one, takes the order, and goes to the [189:53] kitchen. Until the food is finished [189:55] cooking, he remains blocked. Only after [189:58] serving customer one, does he become [190:00] free to go to customer two, take their [190:02] order, and wait again. By default, [190:05] JavaScript works exactly like this. The [190:07] customers are the users, and the waiter [190:09] is the thread. This is synchronous [190:12] blocking behavior. It's called blocking [190:14] because a thread stays idle while [190:16] waiting for a task like cooking to [190:18] finish. Let's see how this looks in [190:20] code. [190:21] Imagine a function called process order [190:24] that takes a long time to complete. When [190:26] JavaScript runs, it might first print [190:28] take order for customer one. Then it [190:31] calls process order. Inside that [190:33] function, it prints processing order for [190:35] customer one. But then it hits a while [190:37] loop running for 3 seconds. While that [190:40] loop runs, JavaScript cannot move to the [190:42] next line. It stays blocked, just like [190:45] our waiter. After 3 seconds, it finally [190:48] prints order processed for customer one, [190:50] and moves to the next line to print [190:52] completed order for customer one. If a [190:55] user encounters this in a real [190:56] application, the interface would freeze, [190:59] which is a terrible user experience. [191:01] This is why asynchronous JavaScript is [191:03] absolutely necessary. Before we dive [191:05] into that, we need to understand how [191:07] JavaScript runs inside the browser. When [191:10] the code runs, it is converted into [191:12] machine language by the JavaScript [191:14] engine. While different browsers have [191:16] different engines, like Chrome's V8, [191:19] Internet Explorer's Chakra, or Firefox's [191:21] SpiderMonkey, Google Chrome is [191:24] considered the most powerful because of [191:26] the efficiency of the V8 engine. Inside [191:28] the browser, there are two main [191:30] components: the runtime environment and [191:32] the engine. The runtime environment [191:34] provides objects like window, document, [191:37] and set timeout. Inside the engine, the [191:40] The important part for us is the call [191:42] stack. JavaScript execution begins with [191:45] a main function. As the code runs line [191:47] by line, functions are pushed onto the [191:49] call stack. For example, console.log is [191:52] pushed. It prints to the console and [191:54] then it's popped up. [191:56] When it hits the process order function, [191:58] that goes onto the stack. If there is a [192:00] 3-second while loop inside, the call [192:02] stack remains occupied. The browser is [192:05] blocked. The user can't even click a [192:07] button. This is the last in, first out [192:10] or LIFO nature of the stack. Now, let's [192:13] see how we can remove this blocking [192:15] behavior by replacing that while loop [192:17] with a built-in function called [192:19] setTimeout. [192:20] In this version, JavaScript behaves [192:22] differently. When it reaches setTimeout, [192:24] it recognizes it as an asynchronous [192:26] function. Instead of waiting, it hands [192:29] the task over to the web APIs, which is [192:31] the part of the runtime environment, and [192:34] immediately moves to the next line. [192:36] While the 3-second timer runs in the [192:38] background in a separate thread provided [192:40] by the browser, the main thread [192:42] continues executing the rest of the [192:44] code. This is why you'll see other logs [192:47] print instantly while the cooking [192:49] happens in the background. Once the web [192:51] API timer finishes, the callback [192:53] function, that means the arrow function [192:55] inside setTimeout, is sent to the [192:57] callback queue. Here, the event loop [192:59] comes into play. Its job is to watch the [193:02] call stack and the callback queue. When [193:04] the call stack is empty, the event loop [193:06] takes the first task from the queue and [193:08] pushes it onto the stack for execution. [193:11] This is how JavaScript performs multiple [193:13] tasks despite being single-threaded. It [193:16] has assistants. This non-blocking [193:19] approach ensures the user can still [193:21] interact with the UI while heavy tasks [193:24] happen in the background. [193:26] However, this creates a new challenge, [193:28] flow control. With setTimeout, we can [193:31] predict the 3-second delay, but in real [193:33] life, we deal with API calls, file [193:36] system reads, or database queries, we [193:38] don't know exactly when those will [193:40] finish. If we can't control the order of [193:42] execution, it becomes a problem because [193:45] the sequence of tasks is often critical. [193:48] Let's go back to our restaurant [193:49] scenario. Now, the waiter takes customer [193:52] one's order and tells the kitchen, "Call [193:54] me back when this is ready." Then he [193:56] immediately goes to table two. He isn't [193:59] blocked, he is free. When the kitchen [194:01] calls him back, he finishes the order. [194:03] In code, we handle this using callback [194:06] functions. By passing a function into [194:08] another function, we can ensure that [194:10] complete order only runs after process [194:12] order is done. This works and it's [194:14] non-blocking, but it leads to a problem [194:17] called callback hell. As you add more [194:19] tasks like complete order two, three, [194:21] and four, the code nests deeper and [194:24] deeper, becoming unreadable. To solve [194:27] this, JavaScript introduced promises. A [194:29] promise is exactly what it sounds like, [194:32] a promise to do something. It can be [194:34] resolved or fulfilled and rejected or [194:37] failed. To use a promise, we use then [194:40] for success and catch for errors. This [194:43] is much more human-friendly. Then [194:45] literally means after. We can also chain [194:48] promises together. If any promise in the [194:50] chain fails, the single catch block will [194:52] handle the error. This is much cleaner [194:55] than nesting callbacks. [194:56] Sometimes, you might want to run [194:58] multiple promises at once. For that, we [195:00] have promise.all, which waits for all of [195:03] them to finish and returns an array of [195:06] results. There is also promise.race, [195:09] which only returns the result of the [195:10] promise that resolves the fastest. While [195:13] promises are great, chaining many then [195:16] blocks can still get messy. Programmers [195:18] prefer writing code that looks [195:20] synchronous even it's asynchronous. This [195:23] is where async await comes in. By adding [195:25] the async keyword to a function, it [195:27] automatically returns a promise. Inside [195:30] an async function, we can use the await [195:32] keyword. Await tells JavaScript to wait [195:34] for that specific asynchronous task to [195:36] finish before moving to the next line. [195:39] Even though it looks like it's waiting, [195:41] it's not blocking the main thread. [195:43] JavaScript skips the my meeting function [195:45] call and continues with other code, [195:47] returning to finish the function once [195:49] the data is ready. We handle errors in [195:51] async await using standard try catch [195:53] blocks, which makes debugging very [195:55] intuitive. To summarize, for the best [195:58] performance, always aim for asynchronous [196:00] non-blocking code. Use callbacks for [196:02] simple tasks, promises to manage more [196:04] complex flows, and async await to keep [196:06] your code clean, readable, and [196:08] organized. I hope this clarifies the [196:11] concept of asynchronous JavaScript for [196:13] you. If you have any questions, feel [196:15] free to comment. [196:19] In today's video, we're going to explore [196:21] an advanced JavaScript concept called [196:23] the memoization technique. In [196:24] JavaScript, we often write functions [196:26] that are very resource hungry or [196:28] computationally exp- -ensive. When these [196:31] functions are repeatedly called, they [196:33] end up doing the same work over and over [196:35] again, which wastes time and hurts [196:37] performance. Imagine calling a function [196:39] multiple times with the same parameters. [196:41] Each time, it recalculates everything [196:44] from scratch, even though the result is [196:46] the same as before. Now, if that [196:48] function is heavy, the performance will [196:50] definitely take a hit, right? [196:52] Memoization is used to solve exactly [196:55] this problem. It's essentially a smart [196:57] approach that stores the result of a [196:59] function the first time it runs, so that [197:02] the next time you provide the same [197:04] input, it can return that result [197:06] immediately without recalculating. So, [197:08] in today's video, we'll see how [197:10] memoization actually works, how to apply [197:13] it, and which concepts we need to [197:15] understand it properly. Let's get [197:17] started without any delay. Let's start [197:19] with a simple example. Imagine we have a [197:21] function called add. This function takes [197:23] a number as a parameter and returns that [197:26] number plus 10. Pretty straightforward, [197:28] right? But, let's assume this function [197:30] is actually doing something very [197:32] expensive or heavy. For instance, it [197:34] might be fetching data from an API, [197:36] performing complex calculations, or [197:38] sending multiple requests. Basically, [197:40] something that uses a lot of CPU and [197:42] memory. Calling such a function [197:44] repeatedly means repeating the same [197:47] heavy work over and over, which is quite [197:49] expensive for our system. This is the [197:51] situation we are imagining. So, we are [197:53] not actually writing a huge function [197:55] right now, but let's assume our add [197:57] function represents that CPU-heavy task. [197:59] Now, when I call the add function with [198:01] the parameter 10, it executes once. But, [198:04] what happens if I call it again with the [198:06] same parameter 10? [198:08] Yes, the add function executes again. In [198:11] other words, calling it twice with the [198:13] same parameter means doing the same [198:14] computation twice. The internal [198:16] calculations happen two times, even [198:18] though the input hasn't changed. Now, [198:20] imagine if I keep calling it with the [198:22] parameter 10 repeatedly, there's [198:24] actually no need to recalculate every [198:26] time, right? Because giving 10 will [198:29] always return 20, but the calculation [198:31] inside the add function still runs each [198:33] time. So, if we want to do this heavy [198:35] work just once and store the result in [198:37] memory, so that next time the same input [198:39] comes, we can directly use that result, [198:41] that's what we call memoization. Let's [198:44] look at an example of this. Simply put, [198:46] when we call the add function, it [198:48] performs its task, right? The add [198:50] function is an independent function. [198:52] Now, if we want it to remember previous [198:54] results, we can't just call it directly. [198:56] Instead, we pass the add function [198:58] through another function. In other [199:00] words, we don't call add directly. We [199:02] send it to another function. This new [199:05] function will handle it like this. I [199:07] want to call this add function with the [199:08] parameter 10 to perform a specific task. [199:11] Check first if the result for this task [199:13] is already stored in our memory. If the [199:15] result is already cached in the [199:17] function's memory, there's no need to [199:18] calculate it again. It can simply return [199:20] the previous result directly. But, if [199:22] the result for the parameter 10 isn't in [199:24] memory, it will call the add function, [199:26] compute the result, and then save that [199:28] result in memory. So, the next time [199:29] someone calls it with the same [199:31] parameter, it can return the cached [199:32] result directly without recalculating. [199:35] This is essentially the concept of [199:36] memoization. I hope it's clear now. So [199:39] far, we have understood the theory [199:40] behind memoization. Now, let's see it in [199:43] practice by implementing it. What we're [199:45] going to do is create a memoized version [199:47] of the add function. We start by writing [199:49] a function like this. Function memo, and [199:52] we will receive func as parameter. [199:54] Here, the function is named memo. This [199:57] memo function takes a parameter called [199:59] func, meaning it accepts another [200:02] function as input. [200:03] That could be our add function. Inside [200:06] the memo function, we will decide how to [200:08] actually memoize the function, just like [200:10] we discussed earlier. [200:11] So, what does the memo function actually [200:13] do? It takes a function as input and [200:15] returns a new function. We can write it [200:18] like this. Return function. This kind of [200:21] function is called a higher-order [200:22] function. That means it's a function [200:24] that either takes another function as [200:26] input or returns a function as output. [200:29] So, to create a memoized version of any [200:31] function, the first concept we need to [200:33] understand is the higher-order function. [200:35] A higher-order function is a function [200:37] that can take another function as a [200:39] parameter, returns a function, or do [200:41] both. In our case, it's doing both. It [200:44] takes a function as input and returns a [200:46] function as output. [200:48] Now, we will pass our add function [200:50] through the memo function. This way, [200:52] inside the memo function, we can decide, [200:55] should we call the add function directly [200:56] or first check if a previous result is [200:58] already cached? So, the memo function [201:01] itself becomes our memoized version, [201:03] right? Now, look, we have already set up [201:06] the entire boilerplate to create a [201:08] memoized function for add. The next [201:11] question is, how do we call this memo [201:12] function? We can do it simply like this. [201:15] Const calculate is equal to memo, and [201:18] pass the add function body. Here, we are [201:20] creating a new variable called [201:22] calculate. Essentially, we are calling [201:23] the memo function and passing the add [201:25] function as a parameter. So, this [201:28] calculate variable becomes our actual [201:30] calculate function, which is really just [201:32] a memoized version of the add function. [201:35] See, the memo function is a higher-order [201:37] function because we're not calling the [201:38] add function directly. Instead, we are [201:40] wrapping it inside another function, and [201:42] that wrapped function is our memo. [201:45] So, what is the memo actually doing? It [201:47] takes the add function as a parameter [201:49] and returns a new function. Inside this [201:51] returned function, we decide whether to [201:53] perform a new calculation or just return [201:55] a previously cached result. Now, we will [201:58] call the calculate function. We write [202:00] console.log and pass the calculate [202:02] function with parameter 10. [202:04] The first time we called the add [202:06] function, we wrote add 10. [202:08] Now, we write calculate 10 in the same [202:11] way. [202:12] On the surface, it looks like the same [202:14] operation, but internally, there's a [202:16] difference. That's because calculate 10 [202:19] is actually executing the function [202:21] returned by memo. In other words, the [202:23] calculate function is the function that [202:25] memo returned. [202:27] So, what does the memo function actually [202:29] return? [202:30] Yes, it returns another function. That [202:32] means calculate is the function returned [202:35] by the memo function. Now, since we are [202:37] passing a parameter into calculate, we [202:39] can receive it dynamically because it [202:41] will go as input to the function [202:43] returned by memo. So, let's say we [202:45] captured it as a parameter called X. [202:47] Now, think about calling the calculate [202:49] function. [202:50] First, we wrote calculate is equal to [202:53] memo and pass the add function. Here, [202:55] the memo function creates and returns a [202:58] new function for the original add [202:59] function. So, calculate is now a [203:01] function that comes from memo. Then, we [203:04] write calculate 10. Since calculate is [203:06] the function returned by memo, the value [203:08] 10 is passed as a parameter to that new [203:11] function. In this way, we have [203:12] essentially set up our boilerplate and [203:14] it's working. Now, the next step is to [203:16] decide how we handle caching or memory [203:19] storage. These tasks will be done inside [203:21] the new function returned by memo. Here, [203:24] we need another concept. That's closure. [203:28] Now look, you have created the calculate [203:30] function just once. What does calculate [203:32] actually do? It gives you a memoized [203:34] version of the add function, right? [203:36] In other words, when you pass any [203:38] function, calculate creates its memoized [203:40] version. So, the question is, what [203:42] actually happens when you call memo add? [203:45] The add function goes in as a parameter [203:47] to the memo function, and memo returns a [203:49] new function. Then, when we write [203:52] calculate 10, we are using the same [203:54] calculate instance each time, right? [203:56] That is, calculate is the instance [203:59] returned by memo. Now, all the work [204:01] happens inside the return function. [204:04] First, we need a cache. So, where should [204:06] we put this cache? We put it inside the [204:08] body of the memo function. For that, we [204:11] write const cached is equal to a blank [204:13] object. Here, we create an empty object [204:16] named cached. You might wonder why we [204:18] placed cached outside the inner [204:20] function. [204:21] That's because a closure is created [204:23] inside the memo function, which allows [204:25] us to retain this cache across multiple [204:27] calls. So, calculate is the function [204:30] returned by memo. No matter how many [204:32] times we call calculate, it's actually [204:34] pointing to the inner function inside [204:36] memo. Whatever you do inside this inner [204:38] function, the cache exists in its outer [204:40] scope. That is, inside the memo function [204:42] itself. As a result, a closure is [204:45] created in the memo function, and every [204:47] time we call calculate, the cache value [204:49] is preserved in memory. In simple terms, [204:52] we are returning a function from memo. [204:54] Now, no matter how many times calculate [204:56] is called, it always uses the reference [204:58] to the inner function returned by memo. [205:01] And the cached object in the outer scope [205:03] of the inner function always retains its [205:05] values. [205:06] Inside the inner function, we decide [205:08] whether to update the cache or return a [205:10] previous value, right? [205:12] So, I hope this is clear now. [205:14] The first time we call calculate with [205:16] 10, what happens? We write calculate 10. [205:19] Since calculate is the inner function [205:21] returned by memo, that inner function [205:23] executes with the parameter 10. [205:26] First, it checks if cached 10. [205:29] Since there's nothing in the cache yet, [205:31] it doesn't enter the if block. Instead, [205:34] it goes to the else block and we print [205:37] to the console console.log calculating [205:39] result. Now, to get the actual result [205:42] inside the else block, we call the [205:44] original function. That is func, which [205:46] we passed as a parameter to the memo, is [205:49] called with the parameter 10. So, we [205:51] write const result is equal to func and [205:54] pass the X. [205:55] Here, func is the original function and [205:57] X is the parameter. This way, we [205:59] calculate the result for the first time [206:01] and then we can store it in the cache. [206:04] Now, we have the result from the add or [206:06] func function stored in result. After [206:09] getting the result, we update the cache [206:11] by writing cache X is equal to result. [206:14] This means we have stored the result in [206:16] the cache under the parameter X. Our [206:19] cache is now set up. Finally, the inner [206:21] function needs to return a value. So, we [206:24] return return result. [206:27] This completes the process for the first [206:28] time. That is, for the else block. [206:31] The second time we call calculate with [206:32] 10, the condition if cached 10 will [206:35] match. That's because last time in the [206:38] else block, we updated the cache. And [206:40] since the cache exists in the outer [206:42] scope and is preserved by the closure, [206:44] it remembers the value, allowing us to [206:46] return the result directly from cache [206:48] 10. [206:49] So, now inside the if condition, we can [206:52] simply write return cache X. [206:56] This creates our memoized version. [206:58] If we look at the output, the first time [207:00] we call calculate, the console will show [207:02] calculating result. That means it [207:04] entered the else block, didn't use the [207:06] cache, called the func function to get [207:08] the result, and then stored that result [207:10] in the cache. [207:11] But the second time we call the same [207:13] calculate 10, it enters the if block and [207:15] the console shows result from cache. [207:18] That means it doesn't recalculate. It [207:21] directly takes the result from the [207:22] cache. [207:23] So, I hope the concept of memoization is [207:25] crystal clear now. We essentially used [207:28] two concepts. One is the higher-order [207:30] function. The memo function itself is [207:32] that higher-order function. [207:34] What did we do? If we call the add [207:36] function directly, it would execute [207:38] repeatedly. So, instead we pass the add [207:40] function to another function. That [207:42] function decides whether to take the [207:44] result from the cache or calculate it [207:46] anew. [207:47] And the function that can make this [207:48] decision is the memo function. [207:50] Now, the point is memo is a higher-order [207:53] function. We stored the memo function in [207:55] a variable called calculate. And later [207:57] we call the inner function returned by [207:59] memo using calculate. [208:01] In other words, calculate is actually [208:03] the function returned by memo. [208:05] This inner function is ultimately what [208:07] decides whether the data exists in the [208:09] cache, whether to store the new data, or [208:12] whether to return the result directly [208:13] from the cache. When we call calculate [208:15] 10 for the first time, the inner [208:17] function executes. At that moment, you [208:20] will see there's no data in the cache [208:21] for the parameter 10. So, it goes into [208:23] the else block, calculates the result, [208:25] updates the cache, and returns it. The [208:28] next time we call it with the same [208:29] parameter 10, the cache is already [208:31] updated. To visualize this, we can write [208:34] inside the inner function console.log [208:36] cache. [208:37] This will show the current state of the [208:39] cache. The first time the cache is [208:41] empty. The second time it shows 20 for [208:44] the parameter 10. In other words, we are [208:47] using the parameter as a unique key. [208:49] Next time, if we pass 10 again, the [208:51] inner function will return 20 directly [208:53] from the cache. If we pass a different [208:55] parameter, it will calculate a new [208:57] result and update the cache. [208:59] I hope this makes the concept clear. [209:01] Now, one last point. It's not always the [209:04] case that there's only one parameter. [209:06] The number of parameters can be [209:07] anything. For example, our add function [209:09] might have unlimited arguments, and we [209:11] want to calculate the sum of all of [209:13] them. So, we won't just call calculate [209:16] 10. For instance, we can write [209:18] console.log calculate 10 20 30 40. [209:22] Here, we are passing multiple arguments. [209:25] In that case, we need to create a [209:26] dynamic function that can handle all [209:28] parameters and sum them up. So, we write [209:32] the add function like this. Function [209:34] add, and we will use the rest operator, [209:37] then x. [209:38] Here, we are using the rest operator to [209:40] capture all parameters and naming it x. [209:43] That way, when the add function [209:44] [clears throat] is called, all arguments [209:46] are collected into an array called x. To [209:49] see this in action, instead of calling [209:51] calculate, we will call add directly. [209:53] First, inside add, we write console.log [209:56] x. [209:57] Then, we call the add function. [210:00] Console.log add 10 20 30 40. [210:04] Looking at the output, we can see what x [210:06] actually is. It will be an array of [210:09] parameters. In other words, when you use [210:11] the rest operator inside add, all [210:13] parameters are collected into the x [210:15] array. So, x simply holds all the [210:17] parameters through the rest operator. [210:19] Now, returning to the implementation of [210:22] add, we need to sum all the parameters. [210:25] Since x is an array, the easiest way to [210:27] sum all its elements is to use the [210:28] reduce method. So, we write return [210:32] x.reduce, and that's how reduce [210:35] operates. We will get the sum and [210:37] current value in the first parameter, [210:39] and then we'll return sum plus current [210:41] value. And in the second parameter, [210:43] we'll pass zero as a default value for [210:45] the first time. We know reduce takes a [210:47] callback function. This callback [210:49] function receives the cumulative value, [210:51] which is the sum so far, and the current [210:53] value, car val. We also provide an [210:55] initial value of zero. So, sum plus car [210:58] value gives the total sum of all [211:00] parameters passed to the add function. [211:03] This is now the implementation of the [211:04] add function. But, keep in mind, this is [211:06] just one way to implement it. Inside the [211:09] memo function, nothing has really [211:11] changed. However, the inner function [211:13] that memo returns will now have more [211:15] than one parameter. What should the [211:17] inner function's parameter be? [211:19] Again, we use the rest operator. Return [211:22] function rest x. Since we will receive [211:25] multiple parameters, the rest operator [211:27] captures all of them. Now, creating the [211:29] cache is a bit different. X is now an [211:32] array. When we call calculate 10 20 30 [211:35] 40, we need to turn that array into a [211:37] key, like a string. This is because the [211:40] result for the combination 10 20 30 40 [211:42] is different from 50 60 70 80. In other [211:46] words, the combination of parameters [211:48] need a unique key. In earlier case, with [211:51] only one parameter, we could directly [211:53] use x as the key. But now, with multiple [211:56] parameters, we need to convert the x [211:58] array into a string or some other unique [212:00] format to use as the key. So, before [212:03] checking the cache, we create a constant [212:05] key. Const key is equal to [212:07] JSON.stringify, and I will pass the x [212:10] parameter. [212:11] Here, we use JSON.stringify because x is [212:14] an array. Stringifying it gives us a [212:16] unique identifier. We can also check [212:19] what the key looks like. Console.log [212:22] key. Then we check the cache like this. [212:24] If cached key, that is, we check the [212:26] cache based on the key. If the key [212:28] already exists in the cache, we return [212:30] cached key directly. If not, we [212:32] calculate the result. To calculate, we [212:35] write const result is equal to func, and [212:38] I will use the rest operator, then x. [212:40] Here, we use the spread operator because [212:42] func is our add function. The add [212:44] function expects each parameter [212:46] separately. If we pass the X array [212:48] directly, it won't work. Using the [212:50] spread operator sends all elements of X [212:53] as separate parameters. Then, we update [212:56] the cache. Cached key is equal to [212:58] result. That is, we save the result [213:00] under the key in the cache and finally [213:02] return result. Now, if we check the [213:05] output, we will see the sum of all [213:06] values. The first array printed came [213:09] from the inner function's console.log. [213:11] But, what we want is to print the cache [213:14] instead. [213:15] console.log cached. Initially, the cache [213:18] is empty. On the first call, calculate [213:20] computes the result and stores it in the [213:22] cache. Now, if we call it again with the [213:25] same combination of parameters, [213:27] console.log calculate 10 20 30 40, you [213:30] will see that the first time the cache [213:32] was empty. The next time the cache has a [213:34] key created for this combination, and [213:36] the result is stored under that key. [213:39] We used stringify so that the key [213:41] becomes a string. This is how the whole [213:43] process works. [213:45] So, I hope it's clear now. This concept [213:48] is commonly asked in job interviews and [213:50] is frequently used in JavaScript for [213:52] performance optimization. If you work [213:54] with React, you are probably familiar [213:56] with the useMemo hook, which essentially [213:58] works in the same way as a higher-order [214:00] function to achieve the same goal. [214:02] So, what once seemed difficult about [214:04] memoization should now feel much easier. [214:07] You'll be able to explain clearly in a [214:08] job interview what memoization is and [214:10] how it works. If you enjoyed this video, [214:13] don't forget to hit the like button. [214:14] Drop a comment to let me know your [214:16] thoughts, and share it with your friends [214:18] so they can get benefited too. Thanks [214:20] for watching, and I will see you in the [214:22] next one. [214:26] We all know that JavaScript is a [214:27] single-threaded programming language. [214:29] But, what does that actually mean? It [214:31] means that, no matter how many processor [214:33] cores your computer or machine has, [214:35] JavaScript will only use one core to run [214:37] its tasks. The rest of the cores [214:39] essentially remain idle. Sounds a bit [214:41] scary, right? Having so many cores yet [214:44] still running everything on just one. [214:46] And that's exactly why JavaScript is [214:48] called a single-threaded programming [214:50] language. Now, the question is, how does [214:52] JavaScript handle this limitation? The [214:54] answer is through the event loop, a [214:56] non-blocking event loop. I already have [214:59] a detailed video in Bangla explaining [215:01] the event loop, and you'll find the link [215:02] in the description if you want to check [215:04] it out. I will soon publish the English [215:06] version of it, but here I will give you [215:08] a short explanation. The most important [215:10] thing about is that it's non-blocking. [215:13] For example, imagine sending a request [215:15] to an API URL. When you hit that URL, [215:18] the entire program doesn't freeze or get [215:20] stuck at that point. Instead, JavaScript [215:23] sends that request off as a network task [215:26] and immediately moves on to the next [215:27] line of code. In other words, no block [215:30] is created in the main thread. The task [215:33] continues in the background elsewhere, [215:35] while JavaScript keeps executing the [215:36] next instruction in the code. After the [215:38] network request is sent, the moment a [215:40] response comes back, the callback [215:42] function inside the previously written [215:44] then block gets executed. However, this [215:47] callback function still runs within the [215:49] main thread. That means during the [215:51] request or while there was latency, the [215:54] rest of the code didn't get stuck. It [215:56] kept executing normally. This is exactly [215:59] how JavaScript manages everything even [216:01] while using a single thread. It doesn't [216:03] just sit idle. Instead, any task that [216:06] can be offloaded is sent to the [216:07] background, while it keeps moving [216:09] forward to execute the next [216:11] instructions. The tasks that must run in [216:13] the main thread happen right there, and [216:15] the ones that can be handled separately [216:17] are completed elsewhere and then return [216:19] to the main thread through callback [216:21] functions. This entire process is what [216:23] we call concurrency. Concurrency means [216:26] handling multiple tasks at the same [216:28] time. To put it simply, imagine a [216:30] restaurant with only one chef. Now, the [216:33] chef is getting many orders at once. [216:35] Cooking is his main job. That's like the [216:37] main thread's work. But apart from [216:39] cooking, there are other tasks, too. [216:41] Like chopping vegetables, grinding [216:43] spices, or other prep work. Instead of [216:46] doing all those himself, the chef [216:48] delegates them to others. We can think [216:50] of these helpers as being like network [216:52] requests. They are not handled by the [216:54] main thread, or in our example, by the [216:56] chef, but instead happens separately on [216:58] the side. Once the task is done, they [217:01] let the chef know the vegetables are [217:03] chopped or the spices are ready. [217:06] At that point, the chef takes those [217:08] prepared items and uses them in cooking, [217:11] or moves forward to the next step in the [217:12] process. In other words, the chef is [217:15] only doing one thing at a time, cooking, [217:17] but the people around him are doing [217:19] different tasks to support him. As a [217:21] result, the chef doesn't have to sit [217:23] idle and wait. He can keep focusing on [217:25] his main job. JavaScript works the same [217:27] way. By using concurrency, it manages [217:30] multiple tasks at once. But there's the [217:32] interesting part. You can't handle [217:34] everything with just concurrency. This [217:36] is where another important concept comes [217:38] in, and that is parallelism. So, the [217:41] question is, what exactly is [217:42] parallelism? In the restaurant example I [217:44] gave, imagine if instead of one chef, [217:47] there were five chefs working together. [217:49] Just like your computer processor has [217:51] five, eight, or even more cores, with [217:53] five chefs, the restaurant could [217:55] definitely handle a lot more orders at [217:57] the same time and serve them much [217:59] faster. At first glance, it might seem [218:01] like the solution is simple. Just add [218:03] more chefs. But in reality, it's not [218:06] that simple. Parallelism means running [218:08] multiple threads at the same time. [218:10] Programming languages that use this [218:11] approach are called multi-threaded [218:13] languages. For example, PHP, C#, C, Go, [218:17] Java, and many other rely on [218:19] multi-threaded architecture. At first [218:21] glance, it might seem like these [218:22] languages should perform much better [218:24] than a single-threaded language like [218:25] JavaScript, since they can utilize all [218:27] the threads. But the truth is, that's [218:30] not always the case. In every situation, [218:32] using a multi-threaded language doesn't [218:35] automatically guarantee better [218:37] performance. Let me explain the reason [218:39] behind this. Let's go back to the [218:40] earlier fetch API example. [218:42] Fetching is actually an IO-intensive [218:44] task. IO stands for input-output. So, [218:47] what exactly are IO-intensive tasks? [218:49] Things like reading and writing to the [218:51] file system, fetching or saving data [218:53] from database, or handling network [218:55] communication. All of these are [218:57] considered IO-related operations. These [218:59] kind of tasks are mostly carried out [219:02] externally. For example, when you read [219:04] or write to the file system, the [219:06] response comes from the disk. The same [219:08] goes for the database. You have to wait [219:09] for the database to respond. And in the [219:11] case of network communication, you wait [219:13] until the server sends back a response. [219:16] None of these tasks happen directly in [219:17] the main thread. They're all [219:19] IO-intensive tasks. Now, here's the [219:21] important part. These tasks are not [219:23] CPU-intensive. During this time, the CPU [219:25] is practically unused or idle. But in [219:28] many multi-threaded programming [219:29] languages, even for IO-intensive tasks, [219:32] CPU threads get blocked. Yet, if the CPU [219:34] could be freed up during these [219:35] operations, tasks like handling network [219:37] requests or performing disk read-writes [219:39] could be completed much faster. And this [219:41] is where JavaScript truly stands out. [219:43] For IO-intensive tasks, JavaScript is [219:46] highly efficient because it manages [219:48] these operations without blocking the [219:49] CPU. That's why JavaScript is so widely [219:52] used in areas like real-world [219:54] communications or network [219:55] communications. And this is the real [219:57] explanation of IO-intensive tasks. Now, [220:00] let's move on to CPU-intensive tasks. [220:03] These are the kinds of operations that [220:05] must be done on the main thread because [220:07] they directly use the CPU. For example, [220:09] running a very large loop, iterating [220:11] through a huge [220:13] array with a for loop, or doing image [220:15] processing or video processing. All of [220:18] these tasks require CPU's power to [220:20] execute. Now, if we take JavaScript as [220:22] an example, since it runs on a single [220:24] thread, these CPU-intensive tasks must [220:27] be handled on the main thread. Unlike [220:29] IO-related tasks such as fetch, these [220:31] can't be handled off to someone else. [220:34] It's not like the chef delegating the [220:36] chopping of vegetables. Here, the chef [220:38] himself has to do the actual cooking. [220:40] That's why until these tasks are [220:42] finished, the main thread actually stays [220:44] blocked. For example, in the for loop [220:46] you see on the screen, the code below it [220:48] can't run until that loop is fully [220:50] completed. But in the fetch example we [220:52] saw earlier, execution was able to move [220:54] on to the next line right away. So, the [220:56] question is how does JavaScript handle [220:58] situations like this? The answer is yes, [221:01] JavaScript does have a solution for it. [221:04] We know that JavaScript is [221:05] single-threaded, but there's the [221:07] surprising part. If needed, JavaScript [221:09] can actually be used in a multi-threaded [221:11] way, and that's the beauty of [221:13] JavaScript. Today, that's exactly what [221:15] we're going to talk about. This is made [221:17] possible through the Web Worker API. [221:19] It's a browser API that allows us to [221:21] create new workers, or in other words, [221:24] new threads from our script. Once [221:26] created, we can offload certain tasks [221:28] from the main thread to these new [221:30] threads. Now, let's look at an example. [221:32] Once you see it, you will understand [221:34] just how amazing this really is. [221:42] So, let's jump straight into the demo. [221:44] We will start with a very simple [221:46] example. As you can see, in our VS Code [221:48] editor, we have an index.html file open. [221:51] Inside it, there are two buttons, each [221:53] with a unique ID. One is total, and the [221:56] other is PG. We have also included a [221:59] script file. This is just a very basic [222:01] HTML setup. If we run this file in the [222:04] browser, we will see two buttons on the [222:06] output. One is the calculate total [222:08] button, and the other is the change [222:10] background color button. Now, what [222:12] happens when someone clicks the change [222:14] background color button? That logic is [222:15] written inside our script.js file. [222:18] For the PG button, we have added a click [222:20] event listener using plain vanilla [222:22] JavaScript. The logic is simple. If the [222:25] background color of the document's body [222:26] isn't green, it will turn it green. And [222:29] if it's already green, then it will [222:31] switch to blue. So, basically, it's [222:33] working like a switch or toggle. If we [222:35] go to the browser and click the change [222:38] background color button, the background [222:39] will first turn green, since it wasn't [222:42] green before. [222:43] Clicking again will change it to blue. [222:45] And with each click, the color will keep [222:48] toggling back and forth. [222:50] I have only added as a simple demo so [222:52] that it becomes easier to explain the [222:54] main concept later on. [222:56] The real part lies in the logic for the [222:57] calculate total button. [222:59] As soon as you click this button, the [223:01] main action begins. If you look closely [223:04] at the code, you will notice there's a [223:05] massive for loop written there. A loop [223:08] that runs up to a number with 10 zeros [223:10] after one, meaning it iterates a very [223:13] large count. Inside this loop, we have [223:15] declared a variable called total. And in [223:18] each iteration, we add one to its [223:20] current Since the loop runs up to such a [223:23] huge number, this operation takes quite [223:25] a bit of time. [223:26] And finally, once the loop is done, the [223:29] value of total gets printed in the [223:30] console. As I mentioned earlier, this [223:33] task you see here is a synchronous [223:35] operation. In other words, it's [223:36] completely CPU intensive and has to be [223:38] executed on the main thread. This isn't [223:41] something that can be handed off to [223:43] someone else. JavaScript itself must [223:46] handle it within its own thread. That's [223:48] why until this task is fully completed, [223:50] the code simply cannot move on to the [223:52] next line. Now, if we see this in action [223:54] in the browser, say we reload the page [223:57] and then click the calculate total [223:59] button, you will notice nothing happens [224:01] right away. [224:02] No output shows up in the console. [224:04] Notice another thing. If I click the [224:07] change background color button during [224:08] this time, the background color doesn't [224:11] change either. [224:12] That clearly means the main thread is [224:14] completely blocked. [224:16] While this huge loop is running, no [224:19] other task can be performed, right? Even [224:21] this line here hasn't executed yet. So, [224:24] until the for loop finishes its work, no [224:27] further code will run and no other [224:29] action can take place. Now notice, as [224:32] soon as the for loop finishes in the [224:33] browser, the background color changes [224:35] instantly and we can also see the output [224:37] in the console, right? At this point, [224:40] everything is back to working normally. [224:42] But, if you click the calculate button [224:44] again, the same thing will happen. Once [224:46] again, the main thread will be blocked [224:48] and during that time, you won't be able [224:50] to do anything else because JavaScript [224:52] runs this loop directly on the main [224:54] thread and while the loop is running, [224:56] the main thread remains blocked, leaving [224:59] no room for any other task to be [225:00] executed. So, this is the real problem. [225:04] Here, I only showed a massive for loop [225:06] as an example, but in real-world [225:08] scenarios, you might face many similar [225:10] situations like processing a large [225:12] array, running complex image processing, [225:15] or handling any other heavy operation. [225:17] These kinds of tasks are CPU-intensive [225:19] and take a significant amount of time. [225:22] But, think about it. If this task could [225:24] be done in the background and once [225:26] completed, we could take the necessary [225:28] action, then the main thread wouldn't [225:30] get blocked at all. You'd still be able [225:32] to continue doing other tasks without [225:35] any interruption. And this is exactly [225:37] the benefit of using the Web Worker API. [225:39] With it, we can take CPU-intensive heavy [225:42] tasks out of the main thread and run [225:44] them in the background instead. In this [225:47] case, our very first step will be to [225:49] create a separate thread, meaning we [225:51] will make a new worker. We will then use [225:54] that worker specifically for the heavy [225:57] tasks without mixing it up with the main [225:59] thread. By doing this, the heavy tasks [226:02] will be handled in a separate thread [226:05] while the main thread stays free to [226:07] continue other work. A webpage can have [226:10] multiple workers if needed, but since we [226:12] only have one heavy task here, we will [226:15] just create a single worker for now. So, [226:17] at the very beginning of our script.js [226:19] file, we will write [226:21] const worker new worker. [226:26] All right. Here, new worker is a class, [226:29] and worker is simply an instance of that [226:32] class. We have now initialized a worker. [226:35] The worker class expects the location of [226:37] your worker script file as its [226:39] parameter. In other words, whichever [226:41] script file path you provided will be [226:43] executed in a separate thread outside of [226:46] the main thread. [226:47] Right now, we don't have a separate [226:49] script file. So, we will create a new [226:52] one and name it worker.js. [226:55] Our worker.js file is now created. We [226:58] haven't written any code inside it yet, [227:00] but before that, let's pass the script [227:03] path into the worker class parameter. [227:05] Since the worker.js file is in the root [227:07] folder, we can simply provide worker.js [227:11] as the parameter in the worker class. [227:14] Now, inside the worker.js file, we will [227:17] write our code. This is where we will [227:19] put the CPU-intensive task or heavy [227:21] operation. But, you might wonder, can we [227:24] just copy the for loop from script.js [227:26] directly into this file? The answer is [227:28] no. That won't work because worker.js [227:32] runs in a completely separate thread, [227:35] and as soon as you used new worker, [227:37] JavaScript instantly created a new [227:40] thread and isolated it entirely from the [227:42] main thread. Because script.js runs on [227:45] one thread, and worker.js runs on [227:47] another. So, there has to be a way for [227:50] them to communicate. Since they're [227:52] working in completely separate spaces, [227:54] you can't just directly import and use [227:57] one inside the other. What we need here [227:59] is messaging. [228:01] Think of it like this. [228:03] You are in Canada, and your friend is in [228:05] Africa. You can't see each other [228:07] directly, but you can send messages. And [228:09] those messages reach the other person. [228:12] The same idea applies here as well. From [228:14] the main thread, you can send messages [228:16] to the worker. For example, something [228:18] like "Hello, brother." And once the [228:20] worker finishes its work, it can also [228:23] send a message back to the main thread. [228:25] Whenever you initialize a worker in [228:27] script.js file, that worker immediately [228:30] knows it can send messages to the main [228:33] thread at any time. Similarly, the main [228:35] thread can also send messages to any of [228:38] its workers. So, there's a communication [228:40] channel. [228:42] This is essentially how the [228:43] communication between the two takes [228:45] place. For example, let's say from the [228:47] main thread, script.js, we can send a [228:50] message to the worker thread. That means [228:52] the worker.js. [228:53] The message would be something like, [228:55] "Brother, I need to run a really a big [228:58] loop. Can you handle it for me?" The [229:00] worker thread will then receive that [229:01] message, run the loop, process the data, [229:04] and once it's done, it will send the [229:07] processed data back to the main thread. [229:09] But before you look at the example, the [229:11] first thing we need to do is cut the big [229:14] for loop out of script.js and move it to [229:17] worker.js. [229:18] So, let's cut the loop from script.js [229:21] file and keep it in the clipboard for [229:23] now. [229:24] We won't paste it into the worker.js [229:27] just yet. We will do that in a moment. [229:29] Now, inside the event listener, we will [229:32] write some logic. The idea is simple. [229:35] When the user clicks the total button, [229:37] we will send a message to the worker. [229:39] How do we send it? [229:41] Right where the for loop used to be, we [229:44] will write worker. [229:46] P. You will notice that VS Code [229:48] immediately shows an auto suggestion. [229:51] Among the options, you will see post [229:53] message. This means that inside the [229:55] worker object or instance, there's a [229:57] property called post message. And the [230:00] The itself is very intuitive. Post [230:02] message simply means we are posting a [230:04] message to the worker. [230:06] Now, if we write worker.postMessage, [230:09] "Hello worker." That message will be [230:11] sent from the main thread to the worker [230:13] thread. But for the worker to actually [230:16] receive this message, we need to set up [230:18] a listener inside the worker.js file. It [230:21] works just like an add event listener. [230:23] So, whenever a message comes in, the [230:26] worker will be able to catch and process [230:28] it. Exactly that's how we [230:31] it inside the worker.js file. [230:33] Here, we can write self.onmessage. [230:37] This means the worker is setting up its [230:39] own listener. Same like we use [230:41] document.addEventListener. [230:43] So, whenever a message arrives from the [230:45] main thread, it will listen for it right [230:47] here. To understand this better, compare [230:50] it with script.js. Just like the global [230:52] window object exists there, in the case [230:54] of a worker, self acts as its global [230:57] object. The difference, however, is that [230:59] a worker thread cannot access the [231:01] browser's DOM. That means it has no [231:04] access to the window object. And you [231:06] also can perform any DOM operations [231:08] inside it. [231:09] However, you can perform any kind of [231:12] CPU-related work here. [231:14] Just remember, there's no DOM access in [231:16] this context. [231:18] That means methods like [231:19] document.getElementById [231:21] or anything similar can't be used inside [231:23] a worker. [231:24] Just like when running JavaScript in the [231:26] browser, we don't always have to write [231:28] window.setTimeout [231:30] or window.document [231:31] because window works in the background [231:33] by default. In the same way, inside a [231:35] worker.js file, writing self.onmessage [231:39] is actually optional. You can simply [231:41] write on message directly or use [231:44] self.onmessage. Both will work. It's [231:47] completely up to you. So, in the [231:49] worker.js file, we will assign an [231:51] anonymous function to on message. Just [231:54] like we usually write a callback [231:55] function in case of [231:56] document.addEventListener. [231:59] In that function's parameter, we will [232:01] receive a message object. [232:03] This is the exact message that comes [232:05] from script.js where we used postMessage [232:08] to send it. [232:10] For now, just to test it simply, we will [232:12] write a console.log message inside the [232:15] function body. That way, whenever the [232:17] worker receives a message from the main [232:19] thread, we will be able to see it [232:20] printed in the console. [232:22] All right. Let's recap what just [232:24] happened. [232:25] From the addEventListener of the total [232:27] button in the script.js file, you will [232:29] send a message to the worker thread [232:32] using the postMessage function. And in [232:34] worker.js, whenever the onmessage [232:37] listener receives that message, it will [232:39] immediately print the message in the [232:40] console. [232:42] Now, let's test it in the browser. [232:45] After reloading the page, click the [232:47] calculate total button. [232:49] You will see that a message object has [232:51] been printed in the console from [232:52] worker.js. [232:54] If you expand that object, you will [232:56] notice it has a data property. And [232:59] inside it, the value is hello worker. [233:02] That means the exact message we sent [233:04] inside the total button's event listener [233:07] in the script.js file with postMessage [233:09] hello worker was received by worker.js [233:13] and it logged that message to the [233:15] console, [233:16] which is exactly what we are seeing in [233:17] the browser. [233:18] Now, we will move on to the real task, [233:21] that CPU-intensive operation, the [233:23] massive for loop we had cut earlier and [233:26] kept in the clipboard. We will now paste [233:28] it into the worker.js file. From this [233:30] point on, running that loop becomes the [233:33] worker's responsibility. Now, the [233:35] mechanism will work like this. Whenever [233:37] you send a message to the worker from [233:39] the total button event listener, the [233:41] onmessage function inside worker.js will [233:44] be triggered. And right there, the [233:46] worker will start running the big loop. [233:49] Let's say, in script.js, you wrote [233:52] worker.postMessage [233:54] "Hello worker, please do the work for [233:57] me." Now, worker.js will receive that [234:00] message. [234:01] Earlier, we were logging message.data to [234:04] the console, but this time instead we'll [234:06] print "Worker has started working." Then [234:10] the worker will run the loop, and once [234:12] the loop is finished, it will print [234:14] "Worker has finished working." [234:17] This way, worker.js will clearly notify [234:20] us when the work has started and when it [234:22] has ended. [234:23] So now, let's check the demo. [234:26] I went to the browser and clicked the [234:28] calculate total button. [234:30] Notice what happened. [234:31] Right away, the console printed "Worker [234:34] has started working." [234:36] That means the worker has begun running [234:38] the loop in the background. During this [234:40] time, I clicked the change background [234:42] color button. [234:43] And the background color changed [234:44] perfectly. [234:46] That's because the main thread isn't [234:47] blocked anymore. The worker is handling [234:50] its task in its own thread, while the [234:52] main thread is free to take care of [234:54] other actions. A little while later, the [234:57] console showed "Worker has finished [234:59] working." That means the worker [235:01] completed its task and notified us. So, [235:04] we clearly saw both when the work [235:06] started and when it finished. And at the [235:09] same time, our main thread stayed fully [235:11] active. We were able to smoothly change [235:13] the page's background color without any [235:15] interruption. But here's the question. [235:18] The worker has finished its job, but the [235:21] output is actually needed in the main [235:23] thread. In real scenarios, you might [235:25] have the worker perform some heavy [235:27] calculation, but then you will need that [235:29] result to display in the DOM or use in [235:31] the main thread. So, how do you send a [235:33] message back from the worker thread to [235:35] the main thread? [235:36] It's very simple. [235:38] After the worker finishes its task, it [235:40] just needs to send a message back to the [235:42] main thread. [235:43] In worker.js, once the loop is done, you [235:46] can use post message to send the result [235:49] to the main thread. [235:50] And inside that message, you can send [235:53] anything you want. [235:54] In our case, we will send the calculated [235:57] total value. [235:58] So, inside post message, we will pass [236:00] the total variable. But how will the [236:03] main thread receive this message? For [236:05] that, we will also need a listener in [236:07] script.js, right? Here's what we'll do. [236:10] Since we already have the worker's [236:12] instance or object, we will call an [236:15] onmessage method on it. [236:18] Notice, we will write worker.onmessage. [236:21] Remember, in the worker.js file, we just [236:24] wrote onmessage to receive messages. The [236:27] same way, here in the main thread, we [236:29] will use worker.onmessage [236:31] to catch messages coming from the [236:33] worker. [236:35] As the value of onmessage, I wrote a [236:37] function. [236:38] This function takes a message parameter, [236:41] which is actually an object. Inside that [236:44] object, the calculated sum will be [236:46] stored in the message.data property. So, [236:49] once the worker thread finishes its [236:51] task, I will print it with console.log [236:55] like this. [236:57] The total is message.data. [237:01] I hope by now you clearly understand the [237:03] entire flow. So, let's see it in the [237:06] browser. [237:07] I reloaded the page, then click the [237:09] calculate total button. [237:11] In the console, I can see the log [237:13] showing that the worker has started its [237:15] task. At the same time, when I click the [237:17] change background button, the background [237:19] color changes as well. [237:21] As you can see, everything in the [237:23] browser is running smoothly without any [237:25] issues. The worker is doing its job in [237:28] the background, while the main thread is [237:30] handling other tasks properly. [237:33] Look at that. The console shows the [237:35] message, worker has finished working. [237:38] And finally, right below it, the total [237:41] value appears. But, remember, this [237:43] output is actually being shown from the [237:45] main thread. The console log came [237:48] directly inside the main thread. [237:50] I hope you can see how beautifully this [237:53] works. By using workers, we can handle [237:56] large, heavy tasks in a very smart and [237:58] efficient way. What I just show you is [238:00] the Web Worker API in the browser. [238:02] Similarly, as you know, JavaScript [238:04] doesn't only run in the browser. It also [238:06] works on the server side. Since Node.js [238:08] is a runtime, it also has a worker API. [238:11] And you can use workers there as well. [238:13] The implementation is a bit different, [238:15] but the core logic and concept remain [238:17] the same. [238:21] Hello everyone. I hope everyone is doing [238:23] well. In today's video, I will talk [238:24] about how to implement multi-threading [238:26] in Node.js. As we all know, JavaScript [238:29] is a single-threaded programming [238:30] language, and Node.js is the runtime [238:32] environment for JavaScript. This means [238:34] that JavaScript essentially runs within [238:36] Node.js, and all operations are handled [238:39] through a single thread. However, when [238:41] we perform tasks that require heavy [238:43] processing, Node.js performance can [238:45] start to decline. Many people mistakenly [238:47] think that Node.js is not good, or that [238:49] JavaScript is flawed. But, there is [238:51] actually a solution. JavaScript can also [238:54] be used effectively with [238:55] multi-threading. Earlier, I showed in a [238:57] video how we can implement [238:59] multi-threading in the browser using [239:01] JavaScript. In today's video, however, [239:03] we'll focus on the back end. Especially, [239:05] how to implement multi-threading on the [239:07] server side using the Node.js runtime. [239:10] As always, we will start today's [239:11] discussion with a simple example. [239:13] Imagine you have a basic Express.js [239:15] application in front of you. Especially, [239:17] a Node.js app. But, let me clarify from [239:19] the start. This tutorial is not meant [239:21] for absolute beginners. It's primarily [239:24] an advanced-level tutorial. When we talk [239:26] about worker threads or multi-threading, [239:28] the concepts naturally become a bit [239:30] complex and high-level. So, before [239:32] diving into this, you need to have a [239:34] clear understanding of the basics. Only [239:36] then can you progress to this level. So, [239:39] let's get started. Here, you have a [239:40] simple Express.js application. I have [239:43] required Express from the Express module [239:45] and then created an Express app in the [239:47] usual way. After that, two routes have [239:49] been added to this application. One is [239:51] {slash} non-blocking and the other is [239:53] {slash} blocking. The {slash} [239:55] non-blocking route is straightforward. [239:57] It simply returns a text response [239:59] saying, "This page is non-blocking." On [240:01] the other hand, the {slash} blocking [240:03] route contains a large loop that runs up [240:06] to 1 million numbers, calculating the [240:08] sum of all these numbers and then [240:10] returning the result. Finally, the [240:12] application is set to run on port 3000 [240:14] using app.listen. I'm running this [240:17] application with Nodemon, so our server [240:19] is now up and running, showing the [240:21] message, "Server is running." Now, if [240:24] you go to the browser and hit the [240:25] {slash} non-blocking URL, you'll see it [240:27] works perfectly fine. But, if you hit [240:30] the {slash} blocking URL, you'll notice [240:32] that it keeps loading and doesn't [240:34] respond immediately. What's even more [240:36] interesting is that if you try to access [240:38] {slash} non-blocking again during this [240:40] time, it also gets stuck and doesn't [240:42] respond. What does this mean? It means [240:45] that while the {slash} blocking route [240:47] was executing, even the {slash} [240:49] non-blocking route became unresponsive. [240:52] Why does this happen? The reason is that [240:54] Node.js is essentially a JavaScript [240:56] runtime. We all know that JavaScript is [240:58] a single-threaded programming language. [241:00] Naturally, Node.js also runs on a single [241:03] thread by default. So, where does the [241:05] problem arise? When you execute the [241:07] {slash} blocking route, the JavaScript [241:09] code runs on the main thread. During [241:12] that time, the main thread is completely [241:14] busy or blocked. As a result, if another [241:17] user tries to access the {slash} [241:19] non-blocking route, they won't get any [241:21] response because the main thread is [241:23] still occupied with the previous task. [241:26] This is why many people think that [241:28] JavaScript is weak because it's [241:30] single-threaded. But, the truth is this [241:33] perception is not entirely accurate. [241:36] With the right approach, JavaScript can [241:38] also be used in a multi-threaded way. [241:41] Let's imagine this is our main thread. [241:43] Now, a question might arise, where [241:46] exactly does JavaScript execute? [241:48] JavaScript runs inside the JavaScript [241:50] engine, which is responsible for [241:52] converting JavaScript code into machine [241:54] code. [241:55] Node.js runs on the V8 engine, the same [241:58] engine used in Google Chrome. [242:00] The V8 engine operates entirely on a [242:02] single thread, meaning everything [242:05] executes within just one main thread. [242:08] Now, the question arises, are there any [242:11] threads other than the main thread? The [242:13] answer is yes. Simply put, besides the [242:16] main thread, there are additional [242:18] threads. These extra threads are used to [242:20] handle different types of tasks. The [242:23] management and implementation of these [242:25] threads are handled by a special library [242:27] called libuv. Now, the question is, what [242:30] exactly is this? It's essentially [242:33] implemented to work alongside your V8 [242:35] engine. While the V8 engine executes [242:37] code on the main thread, there are [242:39] additional threads used for different [242:41] types of tasks. For example, operations [242:44] like database queries, network requests, [242:46] or file read-write tasks are handled by [242:49] these extra threads, and the libuv [242:51] library manages and coordinates them. [242:55] Whenever we perform such tasks, these [242:57] are actually handled by these extra [242:59] threads outside the main thread. libuv [243:01] instructs the V8 engine on how to [243:03] execute these tasks. These kinds of [243:05] tasks are called input-output [243:07] operations, or IO operations for short. [243:10] In other words, when performing file [243:12] read-write, database queries, or network [243:14] requests, these IO operations are [243:17] executed on separate threads without [243:19] blocking the main thread. [243:21] However, if we have something like a for [243:23] loop in our example, or any task that [243:26] primarily requires CPU processing, it [243:28] doesn't fall under IO operations. In [243:31] such cases, the tasks has to be executed [243:33] on the main thread, leaving no option [243:36] but for the main thread to become [243:37] blocked. Let's say a client sends a [243:39] request to the main thread. For this [243:41] request, a query needs to be made to the [243:43] database eventually. So, when a user [243:46] sends a request that requires a database [243:48] query to be served, the request is sent [243:50] to the database, but it doesn't block [243:52] the main thread. Instead, libuv [243:56] query on a separate thread, keeping the [243:58] main thread free. [244:00] In this situation, if another user sends [244:02] a request that doesn't require any [244:04] database query or IO operation, it will [244:06] execute quickly on the main thread. As a [244:09] result, this user can receive a response [244:12] immediately. When the database query [244:14] running on the separate thread [244:15] completes, the result returns to the [244:17] main thread, which then sends it as a [244:19] response. This way, users receive their [244:22] output, and since the main thread [244:24] remains free, other users can continue [244:26] their tasks without delay. [244:28] So, this entire process represents the [244:31] asynchronous nature of JavaScript or [244:33] Node.js. In other words, tasks here are [244:36] not executed synchronously, but [244:39] asynchronously. One user's request is [244:41] being processed on a separate thread, [244:43] and when another user comes along, they [244:46] find the main thread free and can use it [244:48] immediately. This is how the [244:50] asynchronous behavior of JavaScript or [244:52] Node.js works. So, this is how [244:55] everything works effectively. Now, the [244:57] question is, what happens if the main [244:59] thread has a task that doesn't require [245:01] any database access for a user's [245:03] request, but demands heavy CPU [245:05] processing? In that case, the main [245:08] thread will get blocked. Let's say a [245:10] task on the main thread is consuming a [245:12] lot of CPU. If we execute it directly on [245:15] the main thread, the event loop will get [245:17] blocked, and other requests won't be [245:19] able to be processed. [245:21] This is where worker threads come into [245:23] play in Node.js. With worker threads, we [245:25] can spin up a new thread outside the [245:27] main thread to handle CPU heavy [245:29] operations separately. As a result, the [245:32] main thread stays free, allowing other [245:34] requests to be processed immediately. In [245:36] other words, by using worker threads, we [245:39] can run CPU bound tasks asynchronously, [245:42] ensuring that the server's throughput [245:44] and responsiveness are not affected. So, [245:47] looking back at our code example, you [245:49] will see that the task in the {slash} [245:51] blocking route handler is entirely [245:53] running on the main thread, which is why [245:55] this part is blocked. Now, how do we [245:58] solve this? For the solution, we can use [246:00] Node.js built-in worker threads module. [246:03] There's no need to install any separate [246:05] package to use worker threads, as it's a [246:07] core module of Node.js. We can directly [246:10] require the worker from the worker [246:12] {underscore} threads module, and from [246:14] there create a new worker thread. We [246:17] have required the worker, and now it's [246:18] time to use it. First, in the {slash} [246:21] blocking route handler, we need to [246:23] create a new worker. [246:24] When creating a worker, we use new [246:27] worker and provide a file path. This [246:30] path points to the JS file that contains [246:32] the task we want the worker to perform. [246:35] Our heavy operations, like the for loop, [246:37] are placed inside that file. [246:40] So, I have moved this for loop into a [246:42] separate file named worker.js. [246:45] For now, the for loop is pasted there. [246:47] Then, in the {slash} blocking route [246:49] handler of index.js, we provide the path [246:52] to this file when creating the worker. [246:54] Doing this initiates a new thread, which [246:56] will handle our CPU heavy or CPU hungry [246:59] task. [247:00] Let's go back to our slide. [247:02] Here, we have the main thread, and the [247:04] other threads are on the worker threads. [247:07] There's a messaging system in place for [247:09] communication between them. [247:10] In other words, everything ultimately [247:12] has to reach to the main thread. [247:14] Otherwise, we won't be able to provide [247:17] any output. [247:18] Let's say you assign a task to thread B [247:21] and another to thread C. When thread B [247:24] and thread C complete their tasks, they [247:26] need to inform the main thread. To do [247:29] this, they use the messaging system to [247:30] send messages. [247:32] For example, thread C will send a [247:34] message directly to the main thread. It [247:36] works just like exchanging messages in [247:38] an inbox. [247:40] Through this messaging, worker threads [247:42] notify the main thread that their tasks [247:44] are complete and also send the necessary [247:46] data. [247:47] This is exactly the process we will use [247:49] here. So, we have created a worker.js [247:51] file. Now, the question is, how do we [247:54] inform the main thread about the task [247:55] being done in this file? [247:57] For this, we extract parent port from [248:00] worker_threads module. [248:02] The parent port is an object that allows [248:04] the worker thread to communicate with [248:06] the main thread. [248:07] Once the task is complete, we use [248:09] parentPort.postMessage [248:11] and in the bracket, pass the result. In [248:14] other words, we send a message and in [248:15] our case, that message is the result [248:18] data. [248:19] Now, the question is, once I send the [248:21] data, how do you receive it in the [248:23] /blocking handler of index.js? [248:26] This means we need to set up a listener [248:28] inside the handler. For this, we use [248:31] worker.on. What do we listen for? We [248:34] listen for the message event. Just like [248:36] we listen to onclick or other events in [248:39] JavaScript. The first parameter is [248:41] message and the second parameter is a [248:43] callback function where the first [248:45] parameter receives the data. [248:47] Then, we can send this data as a [248:48] response using res.status in the bracket [248:52] 2000, that means the status code, dot [248:54] send and in the bracket, result is data. [248:59] At the same time, if any error occurs, [249:01] we can also listen for it using [249:03] worker.on. [249:05] What do we listen for? We listen to the [249:08] error event. Just like before, the first [249:10] parameter is this time error and the [249:12] second is a callback function where the [249:14] first parameter receives the error [249:16] message. Then, we can show the error [249:18] using res.status, in the bracket, the [249:21] error status code 400. .send, and in the [249:25] bracket, we can pass the error message [249:27] that an error occurred, and pass the [249:30] error message. [249:31] Once this is set up, you will see a [249:33] dramatic change. Let's go to the browser [249:36] and check the {slash} blocking route. [249:38] It's loading, but even while it's [249:40] loading, repeatedly refreshing the [249:42] {slash} non-blocking route works [249:44] perfectly without any issues. [249:47] Now notice, the {slash} non-blocking [249:49] route is accessible, which means even [249:51] though the {slash} blocking route is [249:52] still running, it doesn't affect [249:54] anything. So, we have successfully [249:57] solved this problem. We moved the main [249:59] task to a separate thread outside the [250:01] main thread. [250:02] What does this mean? The main thread [250:04] created a new worker thread and assigned [250:06] the CPU heavy task to it. [250:09] The new thread now works independently [250:11] while the main thread remains free. [250:14] Finally, when the new thread completes [250:16] its task, it also becomes free. Then, [250:19] through the messaging system, the new [250:20] thread informs the main thread, "Your [250:22] data is ready. Here's your data." The [250:25] main thread receives this data and sends [250:27] it to the client as a response. [250:29] Therefore, the tasks that were [250:31] automatically handled on separate [250:33] threads for database queries or file [250:35] read-write operations, because they were [250:37] IO operations, we have now manually [250:39] initiated a thread and used it to handle [250:42] similar CPU heavy tasks. So, I hope you [250:45] now have a clear understanding of how [250:46] this works. Next, we will optimize this [250:49] process further and move on to a [250:51] slightly more advanced level. [250:53] Look, when I go to the {slash} blocking [250:55] route, it's still taking a lot of time. [250:58] This means the optimization isn't fully [251:00] complete yet. We have used a separate [251:02] thread, meaning we have utilized one CPU [251:05] core outside the main thread. But, our [251:08] machine has many more cores. If I open [251:11] the terminal and want to check how many [251:13] cores my machine has, I can run the [251:15] command sysctl /n hw.nCPU. [251:21] This is a Unix command. Running it will [251:23] show how many cores are available. For [251:25] example, I have 10 cores since I'm on a [251:28] Mac. If you are using Linux instead of [251:30] Mac, you have used the nproc command. [251:34] And on Windows, you can use echo number [251:37] of processors to check. [251:39] So, out of the cores available on your [251:41] machine, you can choose to use one or [251:44] multiple cores. I have 10 cores here, so [251:46] I have decided to use four cores for [251:48] this task. In other words, you can [251:51] decide how many cores to allocate for a [251:52] particular job. Now you use multiple [251:55] threads instead of a single thread, the [251:58] task will be completed much faster. So, [252:01] now we will optimize this task. First, [252:03] we create a copy of index.js and name it [252:06] index_optimized.js. [252:08] Then copy all the code from index.js [252:10] into it. Similarly, we make a copy of [252:13] worker.js, name it worker_optimized.js, [252:17] and copy all the code from worker.js. [252:21] Now, coming to the main point. We'll be [252:24] using threads, right? We have planned to [252:26] use multiple threads. Let's say we have [252:29] decided to use four threads. Our machine [252:31] has 10 cores, but we won't use them all [252:34] because that would consume all our [252:36] system resources. So, we will use four [252:38] threads from four of the available [252:40] cores. For this reason, in the [252:42] index_optimized.js file, I have created [252:44] a constant to store the number of [252:46] threads we will use. Let's say I have [252:48] set it to four here, so that later a [252:51] programmer can easily change it if [252:53] needed. Then, I have created a new [252:55] function called create worker. The [252:57] purpose of this function is to create a [252:58] new worker. Here, I'm returning a [253:01] promise because the process of creating [253:03] a worker is performed asynchronously. [253:05] This is because when we create four [253:07] workers, we want the creation process [253:09] itself to happen asynchronously. So, the [253:11] main thread doesn't get blocked. After [253:14] all, creating a worker is essentially a [253:16] separate process. The best practice is [253:18] to create workers asynchronously. That's [253:21] why I created the create worker [253:22] function, which returns a promise. As we [253:25] know, events are listened to inside a [253:27] promise, where resolve and reject are [253:29] used. In the {slash} blocking handler, [253:32] we can handle the worker's result or any [253:34] errors through this promise. To create a [253:37] worker, we use const worker new worker, [253:41] and here we need to provide the path to [253:43] the worker file. Then, as the second [253:45] parameter, we can pass some options. For [253:48] example, if we want to send some data to [253:50] the worker, we use worker data. Inside [253:54] this worker data, we will send a thread [253:56] count, which is stored in our file as [253:58] thread_count. [254:00] For instance, we can pass an object in [254:03] worker data like thread count: [254:05] thread_count. [254:07] When this worker is being created, we [254:09] send some properties from [254:11] index_optimized.js [254:13] as worker data. This is because in [254:15] worker_optimized.js, the worker can use [254:18] parent port to know how many threads it [254:20] should use. So, we have included a [254:22] thread count property in worker data. [254:25] When the worker starts, it reads thread [254:27] count from worker data and works [254:29] accordingly. This is how we have [254:31] designed the create worker function, [254:33] which simply returns a promise. Here, I [254:35] made another change. I removed the [254:38] worker variable from the {slash} [254:39] blocking handler, because we are now [254:41] creating the worker inside the create [254:43] worker function. The event handlers from [254:45] the {slash} blocking handler have also [254:47] been moved into the create worker [254:48] function. The worker is created inside [254:51] the function, and the listeners are set [254:52] up under the worker there. However, [254:55] since these events are being listened to [254:56] inside a promise, we cannot send a [254:58] response directly from there. We will [255:00] send a response inside the slash [255:02] blocking handler. So, from the promise, [255:05] we only use resolve and reject. For [255:07] example, if we get a success message, we [255:10] call resolve and in the bracket, result [255:13] is data. And if there's an error, we [255:16] call reject an error occurred and pass [255:19] the error. [255:20] In other words, the entire process of [255:22] creating a worker has been moved into [255:23] the create worker function, which [255:25] ultimately returns a promise. [255:28] The worker data we provide tells the [255:30] worker what task it should perform. The [255:32] created worker is linked with parent [255:34] port in the worker optimized.js file, [255:37] which essentially communicates with the [255:39] parent thread. Now, we want to divide [255:41] the for loop running up to 1 million [255:43] across four cores. The number of cores [255:46] to use is sent from the [255:47] index.optimized.js file as part of [255:50] worker data. Because this information is [255:52] in worker data, the workers can [255:55] automatically divide and handle the [255:56] tasks among themselves. [255:59] So, in the worker optimized.js file, I [256:01] will get the worker data using worker [256:04] data. Here, we are destructuring the [256:06] worker data from the worker threads [256:09] object. [256:10] Then, in the for loop condition, I will [256:12] use worker data.thread count. [256:15] This means the thread count sent from [256:17] index.optimized.js [256:19] will be used here instead of hardcoding [256:22] the number four. This is best practice [256:25] because the data is passed to the worker [256:27] at the time of its creation. In worker [256:30] optimized.js, we use this to divide the [256:32] work into four parts. Then, four workers [256:35] will be created, meaning the create [256:37] worker function will be called four [256:39] times. Each worker will take one part of [256:42] the work and at the end, all results [256:44] will be combined. This is how the entire [256:47] process is completed. So, in this [256:50] blocking handler, our task is to collect [256:53] the results of the four promises and [256:55] then sum them all. Let's say we stored [256:57] them in an array called worker promises. [257:00] Each entry in this array will hold the [257:03] promise result of a worker. Then, by [257:05] combining all of them, we get the final [257:08] result. Since I need to create four [257:10] workers, I will run a for loop. For let [257:13] I is equal to zero, I less than thread [257:15] underscore count, I plus plus. Inside [257:18] the body of this loop, I will call the [257:20] create worker function each time. This [257:23] means that in every iteration, a new [257:25] worker is created and its promise is [257:28] pushed into the worker promises array. [257:30] So, inside the body of this loop, I will [257:33] call the create worker function four [257:35] times. Each call to create worker [257:37] returns a promise. These four promises [257:40] are pushed into the worker promises [257:42] array like worker promises.push. [257:45] In the bracket, I will call the create [257:47] worker function. This way, each worker [257:50] has its own promise. In the end, since [257:53] all the promises are stored in the [257:54] worker promises array, we can easily [257:57] call the promise.all [257:59] and pass the worker promises. So, I used [258:02] thread results is equal to await [258:05] promise.all in the bracket worker [258:07] promises. As we know, promise.all can [258:11] handle multiple promises together. Here, [258:14] we pass the worker promises array, so [258:16] thread results will contain the results [258:18] of the four promises as separate [258:20] elements like thread results zero, [258:23] thread results one, thread results two, [258:26] and thread results three. Then, we sum [258:29] these results to get the total [258:30] calculation, meaning thread results zero [258:33] plus one plus two plus three gives the [258:36] final result. Since I used await, the [258:39] entire function needs to be async. [258:42] Once everything is done correctly, I can [258:44] send this total result to the client [258:47] using res.status, pass the 200 success [258:50] status code, dot send, and in the [258:52] bracket we can pass the success message. [258:54] Result is total. [258:56] This way, the total calculation works [258:58] correctly, unlike before. So, I hope [259:01] it's clear now. I call the create worker [259:03] function four times here. Each call [259:06] returns a promise. I then awaited all [259:08] these promises together using [259:09] promise.all, so all the results came at [259:12] once. After that, I summed these [259:14] results. The {slash} blocking handler is [259:16] essentially the one executing our [259:18] operational work. So, in the [259:20] worker_optimized.js file, we have [259:22] essentially divided the work into four [259:24] parts. But, it's not necessarily that [259:26] the task will always be a for loop. [259:29] There could be different types of [259:30] complex tasks as well, like image [259:32] processing, data processing, or [259:34] pagination. In such cases, we can't [259:37] always follow the same pattern. So, we [259:38] need to send the necessary data from [259:40] index_optimized.js [259:42] as worker data, and the worker will use [259:45] that data to perform the task in a [259:47] separate process. In the previous [259:49] example, all the steps were sequential. [259:51] So, simply summing the results gave us [259:54] the total. But, in the case of complex [259:56] tasks, we need to use data-driven [259:58] processing. In other complex [260:00] applications, you might need to perform [260:02] different tasks. But, the main concept [260:04] is clear. Any data or property we send [260:07] from here will be received by the [260:09] worker, which will then divide the work. [260:11] Each worker, whether you use four, five, [260:14] or six, will handle its part, and all [260:17] the results will need to be accumulated. [260:19] This is essentially the entire process. [260:22] So, now if I run the index.js file and [260:25] hit the {slash} blocking route in the [260:27] browser, you will notice that it's [260:29] taking quite a bit of time. So, now I [260:31] run the index_optimized.js file. [260:34] If I hit the {slash} blocking route in [260:36] the browser, you will see it takes [260:38] comparatively less time, [260:40] around 3 seconds. Then, if I stop it and [260:43] run the same route with index.js again, [260:45] it takes much longer. [260:47] This shows that by dividing the work [260:49] into four parts, the process becomes [260:52] much easier. Clearly demonstrates how [260:54] worker threads can make our tasks far [260:57] more efficient. So, first we saw in [260:59] index.js how a blocking task can be [261:01] handled in a non-blocking asynchronous [261:03] way. That is, we ran a worker thread and [261:06] because of this worker thread, the main [261:08] thread didn't get blocked, allowing [261:10] other users to continue their tasks [261:12] simultaneously. But, the problem is when [261:14] you use a new thread on the server, [261:16] there isn't just a single core. Usually, [261:18] there are multiple cores, like eight, [261:20] 16, or more. To use multiple cores, we [261:23] first need to find out how many cores [261:25] are available on the server. If the [261:27] server is a Linux server, we can easily [261:29] find out the total number of cores using [261:31] the l nproc command. Then, we can decide [261:34] how many cores to use. For example, [261:36] let's say we decide to use three cores. [261:38] In index-optimized purchase, we have [261:40] implemented a way to divide the work [261:43] among these cores. So, what we did was [261:45] wrap the worker creation process in a [261:47] promise. Since creating a worker takes [261:49] some time and spinning it up isn't [261:51] instantaneous, this process is done [261:53] asynchronously. This way, even if [261:55] multiple users hit the endpoint to [261:57] create workers, the main thread won't be [261:59] blocked. We simply created workers and [262:02] then using the create worker function [262:04] inside a loop, we spawned four or a [262:06] specified number of workers based on the [262:09] thread count. [262:10] Each worker posts messages independently [262:12] and through the listener, we receive [262:14] data from each worker. These results are [262:16] collected via promises, stored together [262:19] in an array, and finally, we sum all the [262:21] results from this array to get the final [262:23] outcome. So, I hope you now understand [262:26] how worker threads work and how we can [262:28] use multi-threaded processes in Node.js. [262:31] It's an excellent concept and a great [262:33] opportunity to learn thoroughly. I I [262:35] also provide a link to the documentation [262:37] in the video description. If you want to [262:38] learn in more depth, you can check the [262:40] details there and grasp it easily. Thank [262:43] you, everyone. [262:46] In this video, I'm going to explain what [262:48] Node.js is and how it actually works, [262:50] but in a super simple way. If you are [262:52] new to Node.js, this video is a [262:54] must-watch because once you get this, [262:57] everything else will start to make [262:58] sense. Don't worry, I'm not going to [263:00] bore you with deep technical stuff. My [263:02] goal is to give you a clear picture of [263:04] Node.js so you really get it. And please [263:07] don't skip this thinking it's just a [263:09] theory. Honestly, every upcoming Node.js [263:12] video I make will rely on the foundation [263:14] you build here. If your dream is to [263:16] become a Node.js developer, the ideas we [263:18] cover today will keep helping you again [263:21] and again in your career. [263:22] Jumping into Node.js code without [263:24] understanding this is like trusting [263:26] someone you have never ever met. [263:29] All right, let's not drag this out. [263:31] Let's dive right in. [263:37] So, what is Node.js? The official site [263:40] describes it as a free, open-source tool [263:43] that runs JavaScript outside the [263:44] browser. With it, developers can build [263:47] servers, web apps, command-line tools, [263:49] and even small scripts. It runs on [263:51] Chrome's V8 engine, and there are two [263:54] key things to notice here. The engine [263:56] itself and what we call the runtime. [263:58] Now, what's a runtime? Simply put, it's [264:01] the place where code actually runs. [264:03] Node.js is a runtime, not a language. [264:06] That's the difference. JavaScript is the [264:08] language. Node.js just gives JavaScript [264:11] a home outside the browser so it can do [264:14] more than just run on a web page. [264:17] And why was JavaScript created in the [264:18] first place? [264:19] To add life to web pages. HTML gives us [264:23] structure, CSS adds style, but neither [264:26] can make a page react or move. That's [264:29] where JavaScript comes in. It made [264:31] websites interactive, dynamic, and [264:33] that's why it's called a programming [264:35] language. Sir Brendan Eich is the [264:37] creator of JavaScript. When he started [264:39] working on it, the first thing he had to [264:42] do was design a programming language. [264:44] But, just creating a language wasn't [264:46] enough. There also needed to be [264:48] something that could understand and run [264:50] that language. In other words, he had to [264:52] build a system that would allow the [264:54] browser to take JavaScript code and [264:56] execute it. Let's start with the first [264:58] part, designing the language. While [265:01] doing this, he had to define certain [265:03] syntaxes. For example, take a function. [265:06] Suppose the function name is my [265:08] function, and inside its body, we write [265:10] console.log. [265:12] Any JavaScript developer would [265:13] immediately recognize this and say, [265:15] "Yes, this is a syntax of a JavaScript [265:18] function." JavaScript has countless such [265:20] syntaxes, just like every other [265:22] programming language. This is what [265:24] defines the language itself. Now, moving [265:27] to the second part, how the language [265:29] actually runs. For this, Brendan Eich [265:31] and his team created the JavaScript [265:33] engine. This engine takes in a .js file [265:36] or JavaScript code and executes it. That [265:39] means it programmatically runs the [265:41] instructions written by the programmer. [265:43] The creators of JavaScript specifically [265:45] built this engine for browsers, so that [265:48] whenever a browser encounters a .js [265:50] file, it can execute it with the help of [265:52] the engine. In simple terms, the [265:55] language and its syntax are what you [265:57] write inside a .js file. That's the [265:59] content. The runtime is what takes that [266:01] content and executes it. But, the [266:03] runtime doesn't work alone. It operates [266:06] within the browser's environment. A [266:08] JavaScript developer writes code that [266:10] interacts with the already loaded [266:12] webpage. This means the code needs [266:15] access to elements like HTML, body, IMG, [266:18] and so on, collectively known as the DOM [266:21] or Document Object Model. You can think [266:24] of the DOM as a giant JavaScript object [266:26] that represents the entire page. With [266:29] access to the DOM, you can manipulate [266:31] and change the page as you need it. So, [266:34] imagine inside the browser, you have a [266:36] JavaScript engine with access to the [266:38] DOM. When you pass it a JavaScript file, [266:41] your code through the engine gets access [266:43] to the DOM and the window object. [266:45] Different browsers implement different [266:46] engines. Firefox uses SpiderMonkey, [266:49] Chrome uses V8, Internet Explorer used [266:52] Chakra, Safari uses JavaScript Core, [266:55] etc. Because different runtimes behave [266:58] slightly differently, JavaScript can [267:00] execute differently across browsers. [267:02] Hence, cross-browser issues comes in [267:04] picture. Among all the engines out [267:06] there, Google Chrome's V8 is one of the [267:08] fastest. Inside Chrome, V8 normally runs [267:11] with access to things like the DOM and [267:13] the window object. But then, a developer [267:15] named Ryan Dahl had a bold idea. What if [267:18] we pull this powerful engine out of the [267:20] browser and run it somewhere else? [267:23] That way, we are no longer limited to [267:25] the browser environment. We can create a [267:27] brand new context. This idea completely [267:30] changed the game because V8 was open [267:32] source and written in C++. Ryan was able [267:35] to take its code, embed it into his own [267:38] C++ project, and build something new [267:40] around it. That new layer gave him the [267:42] ability to connect directly with the [267:44] operating system, allowing access to the [267:46] resource like the file system, the [267:48] network, and the memory, things a [267:50] browser sandbox can't provide. And [267:52] that's how Node.js was born, an open [267:54] source project that uses V8 at its core. [267:57] But instead of being tied to the [267:59] browser, its context is now the [268:01] operating system. This means when [268:04] Node.js runs on a server, it can freely [268:06] use the machine's resources. When [268:08] Node.js runs on a server, it gets access [268:11] to everything on that server. By now, [268:13] you can clearly understand that Node.js [268:15] is not a programming language. It's [268:17] actually a C++ program that we can [268:19] install and run on any machine, just [268:22] like other software. Since it can work [268:24] directly with the operating system, it [268:26] can also run on a server because a [268:28] server is nothing more than a remote [268:30] computer that obviously has an operating [268:32] system. So, I hope there's no more [268:35] confusion about what Node.js really is. [268:37] If someone ever asks you, "What is [268:40] Node.js?" you can simply explain, [268:42] "Node.js is a JavaScript runtime powered [268:44] by the Chrome V8 engine and it can run [268:47] on web servers." Up to this point, we [268:49] have a understood what Node.js is. Now, [268:51] let's look at how it actually works. To [268:54] grasp that, we first need a quick [268:56] overview of how a web server operates. A [268:58] web server is where back-end developers [269:00] like us host web applications. A remote [269:03] client, either a user's browser or a [269:05] mobile app, connects to it. If the [269:08] client is a browser, it generally [269:10] expects HTML. In modern single-page [269:13] applications, the HTML shell may already [269:16] be on the client side and the server is [269:18] mainly asked for data through APIs. On [269:21] the other hand, if the client is a [269:23] mobile app, it typically doesn't need [269:25] HTML at all. It only expects structured [269:28] data, usually in JSON format, delivered [269:31] through API calls. So, in simple terms, [269:34] from the server, we request either HTML [269:36] or data. To fulfill that request, the [269:39] server might internally call other [269:41] servers, query databases, or interact [269:44] with the file system. And after some [269:46] processing, it sends back a response to [269:48] the client. If you ask the server [269:50] something simple, like "What is 1 + 2?" [269:53] it can calculate the answer right away [269:55] and return three. That's just pure CPU [269:57] work, no waiting on anything else. But, [270:01] if the server has to grab data from a [270:03] database, call another server, or read [270:05] from a file, that becomes an I/O-heavy [270:08] task. Those tasks take more time, maybe [270:11] 3 seconds or more. Now, the big question [270:13] is, "What happens if multiple clients [270:15] send requests at the same time?" Let's [270:17] take Java as an example. A Tomcat server [270:20] handles multiple requests using multiple [270:22] threads. I won't go deep into what [270:24] threads actually are, but if you are not [270:26] familiar, you can think of them as tiny [270:29] processors or small programs. The Tomcat [270:31] server usually keeps a pool of threads [270:33] ready in advance. When a new request [270:36] comes in, it gets assigned to one of [270:38] those threads. So, if five requests [270:40] arrived at the same time, five different [270:43] threads are used and they all run in [270:45] parallel, returning responses right [270:48] away. Sounds pretty cool, right? But, [270:51] here's the catch. By default, Tomcat has [270:53] 200 threads. That means it can serve up [270:56] to 200 user requests at once. If more [271:00] requests arrive beyond that, the extra [271:02] one have to wait in line. You can [271:04] increase the number of threads if you [271:06] add more resources, but there's always a [271:09] practical limit to how many threads you [271:11] can actually run. Now, back to Node.js. [271:14] JavaScript is traditionally [271:15] single-threaded programming language. [271:17] There is no extra threading. All the [271:19] requests or tasks are handled by the one [271:22] main thread. So, how can it handle [271:24] multiple concurrent requests without one [271:26] long IO operation blocking others? [271:29] Ryan Dahl could have introduced true [271:31] multithreading directly into JavaScript, [271:34] but that would have fundamentally [271:35] changed the nature of the programming [271:37] language itself. Instead, he chose to [271:40] keep a single main thread for JavaScript [271:42] execution and hand off IO tasks to the [271:45] operating system using asynchronous [271:47] non-blocking mechanisms. Now, let's go [271:49] back to our earlier scenario. We all [271:51] know JavaScript is single-threaded, [271:53] right? That means all requests are [271:55] handled by the main thread. Imagine a [271:57] user makes a request to your Node.js [271:59] server, and that request takes 5 seconds [272:02] to complete. The user will get the [272:04] response after 5 seconds. But, what [272:06] happens if another request comes in [272:08] while the first one is still being [272:10] processed? In that case, the second user [272:13] won't get a response until after 10 [272:15] seconds. The first 5 seconds are spent [272:18] generally for the first response, and [272:20] the next 5 seconds are used for the [272:22] second one. Now, imagine 100 requests [272:25] coming in at the same time. What happens [272:27] then? There's still only one thread. [272:30] As you can see, this quickly becomes a [272:32] very complicated situation. But, does [272:34] that mean Node.js is a bad choice as a [272:37] web server? Not at all. If that were the [272:39] case, Node.js would never have become so [272:42] popular. The truth is, Node.js handles [272:44] these situations in a completely [272:46] different way. So, Node.js is a [272:48] single-threaded runtime, and its primary [272:50] job is to accept user requests. Node.js [272:53] essentially says, "Why should I do all [272:55] the heavy work myself? My main [272:58] responsibility is to accept incoming [273:00] requests. The long-running tasks can be [273:02] handled by my assistants." This means [273:05] the single thread in Node.js will [273:07] properly receive requests, but won't [273:09] block or wait while generating the [273:11] output. That's the game-changing idea. [273:13] Requests don't block the single thread. [273:16] Now, how does Node.js achieve this? It [273:19] relies on two core concepts: [273:21] asynchronous operations and non-blocking [273:23] I/O. Non-blocking I/O means when Node.js [273:26] receives a request involving a [273:28] time-consuming operation, like a [273:30] database query or reading and writing [273:32] large files, it passes that task to its [273:35] assistants, often referred to as [273:37] workers. Once the task is handed off, [273:40] Node.js doesn't wait for the worker to [273:42] finish. Instead, it immediately returns [273:45] to listening for and accepting new [273:46] requests. So, imagine user one sends a [273:49] request. That request is handed to a [273:52] worker for processing, and the main [273:54] thread is now free again. While the [273:56] worker is still busy handling user one's [273:58] task, a new request from user two [274:00] arrives. Because the main thread isn't [274:02] stuck producing user one's response, it [274:05] can smoothly accept user two's request, [274:07] assign the task to another worker, and [274:09] once again free itself up to keep [274:11] accepting more requests. This is how [274:14] Node.js manages to handle many [274:16] concurrent requests efficiently, even [274:18] with a single thread. So, this is [274:20] non-blocking behavior of Node.js. Now, [274:23] imagine this. A request needs heavy pure [274:25] CPU-intensive work, for example, summing [274:28] numbers from 1 to 1 million or image [274:30] processing, machine learning inference, [274:33] big data crunching. Focus here [274:35] carefully. It's not an IO-intensive [274:37] work. It's a CPU-intensive work. That [274:40] means main thread has to process that [274:42] request. So, once again, if the single [274:45] thread itself is tied up with a heavy [274:47] job, it will block other incoming [274:49] JavaScript tasks. That's why Node.js [274:52] isn't the best choice for CPU-bound [274:54] workloads, unless you offload them or [274:57] break them down into smaller parts. [274:59] On the other hand, when it comes to the [275:01] IO-bound tasks like database queries, [275:03] network requests, or file operations, [275:06] Node.js really shines. But, don't get [275:09] the wrong idea. This doesn't mean [275:11] Node.js can't handle CPU-intensive work. [275:14] By CPU-intensive, I am referring to [275:16] tasks that require very high competitive [275:18] processing power. Let's return to the [275:20] previous example once more. When we [275:22] handed off the task to the worker, we [275:24] didn't immediately get a response from [275:26] them, nor did we send any response back [275:28] to the user. So, what happens when a [275:30] worker finished its job? This is where [275:33] the concept of asynchronous or callback [275:36] comes in. [275:37] Once a worker completes its task, it [275:39] triggers a callback. A callback is [275:42] essentially a notification or event that [275:45] the job is done. That's why Node.js is [275:47] often described as having an [275:50] event-driven architecture. Through [275:52] callbacks, we can programmatically [275:53] receive a notification when a worker has [275:56] completed its heavy processing, and at [275:58] that point, we define what happens next. [276:01] This is what makes it asynchronous, [276:04] meaning it doesn't block or follow the [276:06] synchronous execution of the main [276:08] thread, but instead maintains order and [276:11] execution flow internally in its own [276:14] way. I won't dive deeper into the topic [276:16] of asynchronous programming right now [276:17] because it's quite broad on its own. If [276:20] you are interested, I can create a [276:21] detailed and advanced video tutorial [276:23] dedicated entirely to that subject. Just [276:26] let me know in the comments if you'd [276:28] like to see that tutorial. When we are [276:30] learning Node.js, it's absolutely [276:32] essential to talk about the event loop. [276:34] This is one of the core internals that [276:36] every Node.js developer needs to [276:37] understand. So far, we have seen Node.js [276:40] handle both synchronous and asynchronous [276:42] tasks, but who's actually controlling [276:44] all of that behavior? How does a single [276:47] thread manage and coordinate [276:48] long-running IO-intensive operations? [276:51] The answer lies in the event loop. You [276:54] can think of the event loop as an [276:56] infinite while loop that's always [276:58] running in the background, constantly [277:00] checking for tasks that need attention. [277:03] Its job is to keep waiting for new [277:05] tasks, and one by one forward them to [277:07] the appropriate place when required. To [277:10] do this, it relies on several [277:12] components: the task queue, the task [277:15] pool, the completed task queue, and the [277:18] event loop itself. The task queue holds [277:20] all the pending tasks that are waiting [277:22] to be executed. From there, tasks are [277:25] sent into the thread pool one at a time [277:27] for processing. At its core, the event [277:29] loop is a simple concept to grasp, [277:31] though there are many more details and [277:33] deeper mechanics you can explore. If [277:35] you'd like, I can create a separate [277:37] in-depth video dedicated to exploring [277:39] the event loop in detail, but for now, [277:41] here's the key idea. The event loop runs [277:44] continuously like a while loop, keeps [277:46] track of long-running tasks through the [277:48] task queue, assigns them to available [277:51] threads in the thread pool, and when [277:53] those tasks are completed, it passes the [277:55] results back to the main thread. This [277:57] mechanism is what makes Node.js highly [278:00] available and extremely efficient as a [278:02] web server. But, there's one more thing [278:05] to understand. The thread pool and event [278:07] loop are mainly designed to handle IO [278:10] intensive tasks. As I mentioned earlier, [278:12] when it comes to CPU intensive [278:14] operations, the main thread can still [278:16] get blocked. However, in the latest [278:19] versions of Node.js, the team introduced [278:21] the concept of worker threads. With [278:23] worker threads, we can now perform CPU [278:26] intensive tasks without blocking the [278:27] main thread. This is a more advanced [278:30] topic, and I already have a separate [278:32] video on Node.js worker threads where I [278:34] explain how to handle these kinds of CPU [278:36] heavy operations. The link to that video [278:38] is in the video description. By [278:40] leveraging worker threads, I truly [278:42] believe Node.js has the potential to [278:44] expand beyond web servers and play a [278:47] significant role in areas like image [278:49] processing and even machine learning in [278:52] the near future. Finally, you might be [278:54] wondering, "If Node.js is [278:56] single-threaded, then where do these [278:57] workers actually come from?" The answer [279:00] is libuv. It's a special library written [279:03] in C++. The library leverages the [279:06] operating system kernel to provide the [279:08] underlying threads that handle IO [279:10] operations. JavaScript itself always [279:13] runs on a single main thread, but [279:15] Node.js, through libuv, can handle [279:17] multiple IO operations by utilizing [279:20] multiple threads in the background. So, [279:22] the assistants I mentioned earlier are [279:24] nothing but threads working behind the [279:26] scene. When a user sends a request to [279:27] the server, the server itself operates [279:30] as if it's running on a single thread. [279:32] But, in the background, it leverages the [279:34] power of multithreading through its [279:36] workers. This clever and powerful design [279:39] is what makes Node.js blazing fast, [279:41] highly performant, and incredibly [279:43] flexible. You have just navigated the [279:45] deep waters of JavaScript internals. [279:48] From the nuances of the call stack to [279:50] the power of worker threads. You now [279:52] have the conceptual blueprint that [279:55] separates great engineers from the rest. [279:57] This foundation is your greatest asset, [280:00] not just for building high-scale [280:01] applications, but for walking into any [280:04] technical interview with the confidence [280:06] to explain exactly why your code works [280:09] the way it does. If this deep dive [280:11] helped you connect the dots, I would [280:13] love to hear your feedback in the [280:14] comments below. What was your biggest [280:17] aha moment? If you want to keep leveling [280:19] up your engineering mindset, make sure [280:22] to subscribe to my small Logic Base Labs [280:25] YouTube channel for more deep dive [280:27] tutorials. Thank you for watching and [280:29] keep building, keep questioning, and [280:31] keep thinking in a JavaScript way. I [280:34] will see you in the next one.