WEBVTT 1 00:00:00.080 --> 00:00:02.560 If I asked you to add point one and a 2 00:00:02.600 --> 00:00:05.719 point two, you would probably just confidently say point three, right. 3 00:00:05.719 --> 00:00:07.160 I mean, it's basic maths. 4 00:00:06.839 --> 00:00:09.599 Exactly, it's basic math. But if you ask JavaScript to 5 00:00:09.640 --> 00:00:13.359 do that exact same calculation, it spits out zero point 6 00:00:13.400 --> 00:00:16.960 three zero zero zero zero zero zero zero zero zero 7 00:00:17.120 --> 00:00:17.679 zero zero. 8 00:00:17.879 --> 00:00:20.120 Yeah, which is usually the moment a new developer just 9 00:00:20.160 --> 00:00:21.920 stares at their screen in total disbelief. 10 00:00:21.960 --> 00:00:24.760 Oh absolutely, So, today we are taking a deep dive 11 00:00:24.839 --> 00:00:27.559 into why one of the world's most you know, widely 12 00:00:27.640 --> 00:00:32.119 used programming language fundamentally struggles with basic math, and more importantly, 13 00:00:32.399 --> 00:00:36.560 how understanding its hidden quarks can actually make you a master. 14 00:00:36.320 --> 00:00:40.280 Coder because it is a language built on honestly brilliant flexibility. 15 00:00:40.479 --> 00:00:43.560 But that flexibility comes with this massive shadow, like if 16 00:00:43.560 --> 00:00:45.960 you don't know the mechanical rules operating under the hood. 17 00:00:46.240 --> 00:00:48.799 That shadow is exactly where all your worst bugs are 18 00:00:48.799 --> 00:00:49.320 going to hide. 19 00:00:49.320 --> 00:00:51.560 And that is exactly what we are waiting into today. 20 00:00:51.719 --> 00:00:54.359 Welcome to the deep dive. Our mission today is to 21 00:00:54.359 --> 00:00:57.600 move beyond just like memorizing JavaScript syntax, we want to 22 00:00:57.640 --> 00:01:01.079 master its pragmatics. We're using a phenomenal source text today, 23 00:01:01.119 --> 00:01:04.920 Effective JavaScript by David Herman, and the whole goal here 24 00:01:04.959 --> 00:01:07.159 is to pull back the curtain. We want to turn 25 00:01:07.319 --> 00:01:12.400 those frustrating you know, keyboard smashing gotchas into real aha moments, 26 00:01:12.640 --> 00:01:14.799 so you can write highly predictable code. 27 00:01:14.920 --> 00:01:18.159 And you really need that predictability because JavaScript is everywhere. 28 00:01:18.400 --> 00:01:22.280 You're probably dealing with constant information overload, just trying to 29 00:01:22.359 --> 00:01:23.640 keep up with the newest framework. 30 00:01:23.760 --> 00:01:25.239 Well there's a new one every week, right. 31 00:01:25.480 --> 00:01:28.799 But the libraries change every year, the core mechanics do not. 32 00:01:29.480 --> 00:01:33.400 So by taking a structured, respectful pace today, we really 33 00:01:33.480 --> 00:01:35.519 want to cut through all that noise and deliver the 34 00:01:35.640 --> 00:01:38.480 underlying reasons why JavaScript behaves the way it does. 35 00:01:38.640 --> 00:01:40.920 Okay, let's unpack this. We have to start at the 36 00:01:40.959 --> 00:01:45.519 absolute foundation. If you don't understand how a language interprets 37 00:01:45.560 --> 00:01:48.280 basic data, I mean, nothing else built on top of 38 00:01:48.280 --> 00:01:50.159 it will make any sense. Yeah, the data is everything, 39 00:01:50.280 --> 00:01:53.040 and our source material drops a major bombshell right in 40 00:01:53.120 --> 00:01:57.040 chapter one. JavaScript has no true integers. 41 00:01:56.560 --> 00:01:59.200 None, zero, none, whatsoever. 42 00:01:59.319 --> 00:02:01.400 That is why to me, it is. 43 00:02:01.719 --> 00:02:04.840 Every single time you type a one or a forty two, 44 00:02:05.079 --> 00:02:08.479 or like a negative five, JavaScript is actually storing it 45 00:02:08.520 --> 00:02:12.280 as a sixty four bit double precision floating point number. Okay, wait, 46 00:02:12.719 --> 00:02:16.439 it uses the the IE seven fifty four standard, which 47 00:02:16.479 --> 00:02:18.919 is basically just a fancy way of saying it stores 48 00:02:19.000 --> 00:02:21.319 everything as a decimal in binary format. 49 00:02:21.400 --> 00:02:24.479 So even a perfectly whole number like a solid integer, 50 00:02:24.960 --> 00:02:27.520 is secretly carrying decimal point baggage. 51 00:02:27.599 --> 00:02:30.879 Yes, exactly, and this is exactly why your point one 52 00:02:30.960 --> 00:02:32.719 plus point two equation fails. 53 00:02:32.840 --> 00:02:34.000 Okay, break that down for me. 54 00:02:34.240 --> 00:02:36.159 Think about how we do math in base ten like 55 00:02:36.240 --> 00:02:38.840 normal decimals. If you try to write the fraction one 56 00:02:38.960 --> 00:02:41.560 third is decimal, you literally can't do it perfectly. You 57 00:02:41.599 --> 00:02:43.240 get point three three three repeating forever. 58 00:02:43.400 --> 00:02:45.080 Right. Eventually you just have to chop it off and 59 00:02:45.120 --> 00:02:46.039 you lose a tiny bit of. 60 00:02:46.039 --> 00:02:50.120 Precision exactly because base ten can't cleanly divide by three. Well, binary, 61 00:02:50.159 --> 00:02:52.879 which is base two, has that exact same problem with 62 00:02:52.919 --> 00:02:56.159 fractions like one tenth. It cannot cleanly represent point one. 63 00:02:56.280 --> 00:02:59.000 Oh so it creates a repeating decimal in binary. 64 00:02:59.080 --> 00:03:02.439 Yes, it creates repeating binary decimal, and the computer has 65 00:03:02.439 --> 00:03:04.599 to chop it off at sixty four bits, which leaves 66 00:03:04.599 --> 00:03:06.960 this microscopic fraction of a remainder. Oh wow, So when 67 00:03:07.000 --> 00:03:10.439 you add two of those imprecise binary decimals together, that 68 00:03:10.560 --> 00:03:14.199 tiny little remainder overflows into your visible result, and boom, 69 00:03:14.240 --> 00:03:18.479 you get that bizarre point three zero zero zero zero 70 00:03:18.639 --> 00:03:21.439 zero zero zero zero zero zero zero zero. 71 00:03:21.439 --> 00:03:23.599 Four that makes so much sense. It's not a bug 72 00:03:23.639 --> 00:03:26.520 at all. It's just a fundamental limitation of trying to 73 00:03:26.520 --> 00:03:29.159 map base ten fractions onto base two hardware. 74 00:03:29.280 --> 00:03:29.759 Exactly. 75 00:03:30.319 --> 00:03:33.080 Well, wait, let me logic through something here. If every 76 00:03:33.120 --> 00:03:36.479 single number is a floating point, decimal bitwise operator shouldn't 77 00:03:36.479 --> 00:03:39.000 even work. I mean, you can't flip binary bits on 78 00:03:39.000 --> 00:03:42.919 a floating decimal point. Right, bitwise math inherently relies on 79 00:03:43.080 --> 00:03:45.319 strict thirty two bit integers. 80 00:03:45.599 --> 00:03:48.080 You are entirely correct. Technically, you shouldn't be able to 81 00:03:48.120 --> 00:03:51.319 do it. But JavaScript does something incredibly sneaky behind your 82 00:03:51.319 --> 00:03:53.639 back to make it work anyway, of course it does. Yeah, 83 00:03:53.680 --> 00:03:55.919 So when you use a bitwise operator, the engine silently 84 00:03:55.960 --> 00:03:58.360 takes your sixty four big float, It actually converts it 85 00:03:58.400 --> 00:04:01.120 into a thirty two bit interature, performs a bitwise math 86 00:04:01.159 --> 00:04:03.919 on it, and then secretly converts the result back into 87 00:04:03.960 --> 00:04:05.960 a standard sixty four bit floating point. 88 00:04:06.039 --> 00:04:06.800 Are you serious? 89 00:04:07.000 --> 00:04:09.639 Yeah? It all happens completely invisibly and just a fraction 90 00:04:09.719 --> 00:04:10.919 of a millisecond. 91 00:04:10.719 --> 00:04:14.400 Talk about doing things behind my back. That actually brings 92 00:04:14.439 --> 00:04:18.120 us to another major theme in Herman's book, implicit coercion. 93 00:04:18.199 --> 00:04:20.399 Oh yeah, the engine's favorite party trick. 94 00:04:20.680 --> 00:04:24.519 Seriously, the engine is just constantly trying to be forgiving. 95 00:04:24.759 --> 00:04:27.439 For example, the book points out that if you write 96 00:04:27.439 --> 00:04:30.360 the number three plus the boole and true, JavaScript just 97 00:04:30.360 --> 00:04:33.399 decides sure true is basically one, so that equals four. 98 00:04:33.560 --> 00:04:38.040 It just guesses right, or the plus operator being completely overloaded, 99 00:04:38.319 --> 00:04:40.480 like if you add the string two and the number 100 00:04:40.480 --> 00:04:43.000 three breaks the tie and favor strings and just gives 101 00:04:43.040 --> 00:04:44.040 you the string twenty three. 102 00:04:44.199 --> 00:04:48.040 Yeah, it acts like this hyper eager assistant. It sees 103 00:04:48.079 --> 00:04:51.079 a typo or a type mismatch, and instead of just 104 00:04:51.120 --> 00:04:53.680 stopping everything to ask you what you meant, it just 105 00:04:53.759 --> 00:04:57.720 guesses based on this really rigid, hard coded set of rules. 106 00:04:58.399 --> 00:05:00.399 You know, I honestly want to push back on the 107 00:05:00.439 --> 00:05:01.439 author a little bit here. 108 00:05:01.560 --> 00:05:02.240 Okay, go for it. 109 00:05:02.319 --> 00:05:04.680 If the language is genuinely trying to be helpful, why 110 00:05:04.680 --> 00:05:07.600 shouldn't we just let it coerce things? Doesn't it save 111 00:05:07.720 --> 00:05:10.360 us time? I mean, if I tap a string of two, 112 00:05:10.439 --> 00:05:12.839 the computer converting it for me, feels like one less 113 00:05:12.839 --> 00:05:14.639 line of code I have to write I. 114 00:05:14.600 --> 00:05:19.800 Get that, but consider the alternative when that eger assistant 115 00:05:19.839 --> 00:05:23.399 guess is wrong, like semantics usually fail because computers simply 116 00:05:23.399 --> 00:05:26.279 cannot read minds. Fair point. Let's say you have a 117 00:05:26.319 --> 00:05:29.720 variable that's supposed to be a number. Right, You're calculating 118 00:05:29.759 --> 00:05:32.879 a user's cart total on an e commerce site, but 119 00:05:32.959 --> 00:05:36.079 due to some weird bug in an API, it accidentally 120 00:05:36.079 --> 00:05:40.319 becomes null. Okay, not ideal in a stricter language. The 121 00:05:40.480 --> 00:05:42.399 very moment you tried to add a price to null, 122 00:05:42.519 --> 00:05:46.000 the program completely crashes. Y. It stops and tells you 123 00:05:46.040 --> 00:05:49.879 exactly where the error happened. But in JavaScript, JavaScript just 124 00:05:50.160 --> 00:05:54.199 silently coerces null to zero. Oh no, yeah, it just 125 00:05:54.279 --> 00:05:57.560 completes the math. So now your calculation is entirely wrong. 126 00:05:58.000 --> 00:06:00.519 That bad data propagates all the way through your day database, 127 00:06:00.759 --> 00:06:03.160 and your user gets charged the wrong amount. That's horrible, 128 00:06:03.160 --> 00:06:05.120 And the worst part is the error doesn't happen where 129 00:06:05.160 --> 00:06:08.120 the actual mistake was made. It happens like miles down 130 00:06:08.120 --> 00:06:12.040 the road. It makes debugging an absolute nightmare because implicit 131 00:06:12.120 --> 00:06:15.120 coercion hides your type bears instead of catching them. 132 00:06:15.319 --> 00:06:18.319 Okay, yeah, that is a terrifying scenario, which, honestly it 133 00:06:18.399 --> 00:06:20.879 leads us perfectly into Nan not a number. Ugh. 134 00:06:21.319 --> 00:06:25.120 Nan the most ironically named value in the entire language. 135 00:06:24.839 --> 00:06:27.920 Right, considering the type of operator literally classifies Nan as 136 00:06:27.959 --> 00:06:28.480 a number. 137 00:06:28.600 --> 00:06:32.279 It's hilarious. It's a number that means not a number. 138 00:06:32.399 --> 00:06:35.920 And testing for it is notoriously broken. The book mentions 139 00:06:35.920 --> 00:06:39.120 that if you use the strict equality operator nanin equals 140 00:06:39.160 --> 00:06:42.920 so nan actually evaluates to false. Yep, if a value 141 00:06:42.959 --> 00:06:45.920 isn't equal to itself, how do you reliably check for 142 00:06:45.959 --> 00:06:47.480 it without just pulling your hair out? 143 00:06:47.720 --> 00:06:50.639 Well, the author actually provides a brilliant, super reliable trick 144 00:06:50.680 --> 00:06:53.480 for this. You check if a value is unequal to itself. 145 00:06:53.480 --> 00:06:56.120 Wait what Yeah, So if you write x equals x 146 00:06:56.399 --> 00:07:00.199 and that specific statement evaluates to true, then x is 147 00:07:00.199 --> 00:07:03.639 absolutely guaranteed to be nan. Because of that IEE standard 148 00:07:03.720 --> 00:07:06.759 we talked about earlier, Nan is literally the only value 149 00:07:06.759 --> 00:07:09.240 in the entire language where that inequality holds true. 150 00:07:09.319 --> 00:07:12.399 Wow, that is a phenomenal nugget of knowledge, and it 151 00:07:12.399 --> 00:07:14.120 ties right back to why we have to avoid the 152 00:07:14.120 --> 00:07:16.279 double equals operator and just rely on triple equals. 153 00:07:16.360 --> 00:07:17.959 Always use triple equals. 154 00:07:17.639 --> 00:07:21.279 Because double equals triggers that eager assistant to start coercing 155 00:07:21.319 --> 00:07:25.240 types again applying this massive, condoluted table of rules. But 156 00:07:25.319 --> 00:07:30.240 triple equals is strict no coercion, just a direct, honest comparison. 157 00:07:30.480 --> 00:07:34.079 And using strict equality isn't just about avoiding bugs, you know, 158 00:07:34.399 --> 00:07:37.800 It's about communicating your intent to whoever reads your code 159 00:07:37.800 --> 00:07:40.920 six months from now. It basically says, hey, I expect 160 00:07:40.920 --> 00:07:43.759 this exact type and I accept no substitutions. 161 00:07:43.879 --> 00:07:46.519 Absolutely, So the engine is constantly trying to guess our 162 00:07:46.560 --> 00:07:50.600 intent with data types. But this eger assistant behavior. It 163 00:07:50.639 --> 00:07:53.120 doesn't stop at data. No, it actually tries to guess 164 00:07:53.120 --> 00:07:56.079 the structure of your code too. If you forget punctuation, 165 00:07:56.199 --> 00:07:58.480 it will literally rewrite your syntax for you. 166 00:07:58.800 --> 00:08:01.879 Let's talk about automatics Colon insertion or ASI. So. 167 00:08:01.920 --> 00:08:05.000 ASI was originally designed as an error correction mechanism. The 168 00:08:05.079 --> 00:08:08.199 idea was if a developer accidentally leaves off a statement 169 00:08:08.279 --> 00:08:11.800 terminating semicolon, the engine tries to infer where it belongs 170 00:08:11.839 --> 00:08:13.759 and inserts one invisibly. 171 00:08:13.439 --> 00:08:14.720 To keep the script from breaking. 172 00:08:15.040 --> 00:08:17.800 But it gets it wrong. It doesn't actually read your mind. 173 00:08:18.120 --> 00:08:22.879 The book highlights five specific problem characters that completely disable 174 00:08:22.959 --> 00:08:26.639 this insertion, the open parenthesis, the open square bracket, the 175 00:08:26.680 --> 00:08:30.519 plus sign, the minus sign, and the forward slash yeah. 176 00:08:30.560 --> 00:08:34.159 And to visualize this like without looking at a screen, 177 00:08:34.840 --> 00:08:37.799 imagine you write a variable assignment online one, just let 178 00:08:37.840 --> 00:08:40.679 result equals a plus b. Yeah, but you forget the semicolon. 179 00:08:40.879 --> 00:08:41.200 Okay. 180 00:08:41.279 --> 00:08:44.240 Then online two you decide to group some completely separate 181 00:08:44.279 --> 00:08:47.559 map together using an open parenthesis. So line two just 182 00:08:47.600 --> 00:08:49.240 starts with X plus y, right. 183 00:08:49.279 --> 00:08:52.080 And because JavaScript doesn't see a semi coolon online one, 184 00:08:52.279 --> 00:08:54.759 it looks at the open parenthesis online two and assumes 185 00:08:54.759 --> 00:08:57.159 they are connected. It thinks you are trying to call 186 00:08:57.320 --> 00:08:59.799 a plus b as a function and passing x plus 187 00:08:59.840 --> 00:09:00.799 one as the argument. 188 00:09:00.960 --> 00:09:03.200 Exactly. It just jams the two lines together and you 189 00:09:03.200 --> 00:09:06.840 get this completely baffling not a function error. And there's 190 00:09:06.879 --> 00:09:10.080 actually a secondary trap here called restricted productions, where it 191 00:09:10.120 --> 00:09:10.840 does the exact. 192 00:09:10.639 --> 00:09:14.120 Operation where it forcefully inserts a semicolone where you explicitly 193 00:09:14.159 --> 00:09:17.399 did not want one, exactly, a classic return statement bug. 194 00:09:17.679 --> 00:09:21.639 Yes, this gets everyone. Imagine you write the keyword return, 195 00:09:22.200 --> 00:09:24.200 and because you want your code to look really clean 196 00:09:24.200 --> 00:09:27.440 and readable, you hit enter and put the object you're 197 00:09:27.480 --> 00:09:30.600 returning on the next line down makes sense. The JavaScript 198 00:09:30.600 --> 00:09:33.879 engine sees return, hits the new line, and instantly says 199 00:09:34.039 --> 00:09:37.600 oh statement over and just drops an invisible semicolon right 200 00:09:37.639 --> 00:09:38.200 after return. 201 00:09:38.279 --> 00:09:41.960 So your function just silently returns undefined. Yep, and that 202 00:09:42.039 --> 00:09:45.000 beautifully formatted object sitting on the next line is just 203 00:09:45.159 --> 00:09:48.799 dead code. It will never be reached, never invisible bugs. 204 00:09:48.879 --> 00:09:50.200 It's honestly fascinating. 205 00:09:50.320 --> 00:09:52.679 It forces you to realize that white space and new 206 00:09:52.720 --> 00:09:56.559 lines are not just aesthetic in JavaScript like they actively 207 00:09:56.600 --> 00:09:59.799 participate in how the compiler interprets your logic. 208 00:09:59.519 --> 00:10:02.240 Which is a huge mental shift. Yeah, and this invisible 209 00:10:02.240 --> 00:10:05.519 shifting of code brings us to another massive structural quirk 210 00:10:06.279 --> 00:10:07.240 variable hoisting. 211 00:10:07.320 --> 00:10:08.000 Oh hoisting. 212 00:10:08.120 --> 00:10:11.559 JavaScript lacks block scoping, well except for catch blocks. In 213 00:10:11.600 --> 00:10:14.159 a lot of other languages, if you declare a variable 214 00:10:14.159 --> 00:10:16.480 inside an if statement or a for loop, it only 215 00:10:16.519 --> 00:10:19.639 exists within those brackets. It is contained, right But. 216 00:10:19.639 --> 00:10:23.919 In JavaScript using the traditional var keyword, that containment just 217 00:10:24.000 --> 00:10:28.639 doesn't exist. If you declare varx equals five deeply nested 218 00:10:28.679 --> 00:10:32.960 inside a loop, the engine implicitly moves or hoists the 219 00:10:33.039 --> 00:10:36.200 declaration of x to the very top of its enclosing function. 220 00:10:36.960 --> 00:10:40.080 But just the declaration right, not the assignment. 221 00:10:39.919 --> 00:10:42.759 Correct, So the space in memory is created at the top, 222 00:10:43.039 --> 00:10:45.639 but the value of five isn't actually assigned until the 223 00:10:45.679 --> 00:10:48.159 engine runs down to the specific line where you originally 224 00:10:48.159 --> 00:10:48.480 wrote it. 225 00:10:48.519 --> 00:10:51.840 Okay, here's an analogy for hoisting. It's like a stage 226 00:10:51.840 --> 00:10:54.639 director taking all your character introductions and moving them to 227 00:10:54.679 --> 00:10:56.840 the very first scene of the play so the audience 228 00:10:56.879 --> 00:11:00.600 knows they exist. I like this, but the director leaves 229 00:11:00.639 --> 00:11:04.679 their actual costume changes and prop assignments exactly where you 230 00:11:04.720 --> 00:11:05.960 originally wrote them in X two. 231 00:11:06.080 --> 00:11:09.399 Yeah, the director moves the actors but leaves their props behind, 232 00:11:09.600 --> 00:11:12.039 so if they try to use that prop and scene one, 233 00:11:12.200 --> 00:11:14.919 the result is just undefined exactly. And this is why 234 00:11:14.960 --> 00:11:18.279 hoisting causes so many daily bugs. If you don't realize 235 00:11:18.320 --> 00:11:20.519 a loop variable is being hoisted to the top of 236 00:11:20.519 --> 00:11:24.039 your function, you might accidentally overwrite another variable with the 237 00:11:24.080 --> 00:11:25.440 exact same name higher. 238 00:11:25.200 --> 00:11:29.000 Up, which is exactly why the author emphasizes manual hoisting 239 00:11:29.039 --> 00:11:32.639 as a best practice. Just literally write all your VAW 240 00:11:32.679 --> 00:11:35.360 declarations at the very top of your function manually. 241 00:11:35.480 --> 00:11:37.360 Yeah, be your own stage director. 242 00:11:37.120 --> 00:11:40.759 Right, because it visually matches how the engine actually interprets 243 00:11:40.759 --> 00:11:43.919 the code, which saves you from those crazy loop variable 244 00:11:44.120 --> 00:11:48.559 overwrite bugs. You are basically organizing the actors before the 245 00:11:48.600 --> 00:11:49.559 play begins. 246 00:11:49.799 --> 00:11:52.000 It really is about writing code the way the compiler 247 00:11:52.039 --> 00:11:55.679 reads it. When your mental model matches the engine's mechanical model, 248 00:11:56.000 --> 00:11:57.159 the bugs just disappear. 249 00:11:57.600 --> 00:12:00.799 So true. Okay, so hoisting shows us how jobscript moves 250 00:12:00.919 --> 00:12:05.000 variable declarations around in a function's scope. But what happens 251 00:12:05.039 --> 00:12:07.399 when functions hold onto those variables across time? 252 00:12:07.759 --> 00:12:08.919 Now we're getting to the good stuff. 253 00:12:09.000 --> 00:12:11.080 Yeah, this brings us to what might be the language's 254 00:12:11.120 --> 00:12:14.720 most powerful expressive feature closures. 255 00:12:14.879 --> 00:12:17.919 Closures are incredibly elegant once you strip away all the 256 00:12:17.919 --> 00:12:22.200 computer science jargon. In really simple terms, a closure allows 257 00:12:22.200 --> 00:12:25.919 a function to remember variables from its outer scope even 258 00:12:25.960 --> 00:12:29.039 after that outer function has completely finished executing. In return, 259 00:12:29.320 --> 00:12:29.600 it's like. 260 00:12:29.600 --> 00:12:32.000 A memory that outlives the event itself. 261 00:12:32.360 --> 00:12:33.399 That's a great way to put it. 262 00:12:33.480 --> 00:12:38.039 But here is the crucial, often misunderstood detail from Herman's book. 263 00:12:38.919 --> 00:12:43.159 Closures store references to their outer variables. They do not 264 00:12:43.320 --> 00:12:46.320 store copies of their values at that frozen moment in time. 265 00:12:46.480 --> 00:12:50.879 Yes, and this specific detail trips up seasoned developers constantly 266 00:12:51.559 --> 00:12:54.600 because it's a reference. It means the closure is looking 267 00:12:54.679 --> 00:12:55.799 at a live variable. 268 00:12:55.879 --> 00:12:56.879 Okay, give me an example. 269 00:12:57.360 --> 00:13:00.440 Think about a for loop that runs three times from 270 00:13:00.519 --> 00:13:04.279 zero to two. Inside that loop, you create three different 271 00:13:04.320 --> 00:13:07.279 button click functions, and each one is supposed to print 272 00:13:07.360 --> 00:13:08.360 the current loop number. 273 00:13:08.440 --> 00:13:10.840 Okay, so you would logically expect the first button to 274 00:13:10.840 --> 00:13:13.000 print zero, the second to print one, and the third 275 00:13:13.039 --> 00:13:14.919 to print two naturally, but. 276 00:13:15.200 --> 00:13:17.320 They don't capture a frozen copy of the number. They 277 00:13:17.360 --> 00:13:19.759 capture a live reference to the single variable eye. 278 00:13:19.840 --> 00:13:20.039 Oh. 279 00:13:20.480 --> 00:13:22.320 So, by the time the loop is finished running, I 280 00:13:22.519 --> 00:13:26.360 is incremented to its maximum value, which is three. Later, 281 00:13:26.639 --> 00:13:29.279 when a user finally clicks one of those buttons, the 282 00:13:29.360 --> 00:13:31.799 closure looks up the current value of IE, and every 283 00:13:31.799 --> 00:13:33.200 single button just prints three. 284 00:13:33.320 --> 00:13:36.279 That is so frustrating. So to fix it, you basically 285 00:13:36.320 --> 00:13:39.240 have to freeze time for each iteration. You can't just 286 00:13:39.320 --> 00:13:42.879 let the closure point to the main loop variable, right, You. 287 00:13:42.799 --> 00:13:46.519 Need to force a brand new, completely isolated local scope 288 00:13:46.799 --> 00:13:50.440 for every single iteration. And the classic JavaScript workaround for 289 00:13:50.480 --> 00:13:55.159 this is using an IIE an immediately invoked function expression. 290 00:13:55.200 --> 00:13:57.639 Okay, let's slow that down for the listener. How exactly 291 00:13:57.679 --> 00:13:59.399 does an IE freeze time? 292 00:13:59.519 --> 00:14:01.840 Okay, so instead of just creating the closure directly in 293 00:14:01.879 --> 00:14:06.039 the loop, you wrap it inside a completely separate temporary function. 294 00:14:06.399 --> 00:14:08.799 You pass the current loop number into that temporary function 295 00:14:08.840 --> 00:14:11.120 as an argument, and you command the engine to run 296 00:14:11.159 --> 00:14:12.360 it right then and there. 297 00:14:12.440 --> 00:14:15.440 Ah immediately invoked exactly. 298 00:14:15.360 --> 00:14:18.000 That temporary function locks the value in place for that 299 00:14:18.039 --> 00:14:21.919 specific iteration, and then returns your closure safely sealed inside 300 00:14:21.960 --> 00:14:22.960 that frozen environment. 301 00:14:23.279 --> 00:14:25.080 Okay, Wait, I have an insight here. I want to 302 00:14:25.120 --> 00:14:28.519 test with you. Sure, if closures store live references rather 303 00:14:28.519 --> 00:14:32.399 than static values, doesn't that mean multiple closures can actually 304 00:14:32.399 --> 00:14:36.320 communicate by modifying the exact same outer variable. 305 00:14:36.679 --> 00:14:39.360 Yes, you just hit on one of the most powerful 306 00:14:39.480 --> 00:14:42.360 architectural patterns in the language. Really, yeah, it's not a 307 00:14:42.399 --> 00:14:45.559 bug at all, it's a massive superpower. This is the 308 00:14:45.600 --> 00:14:50.000 foundation of the box pattern. Imagine a function that defines 309 00:14:50.039 --> 00:14:54.559 a single private variable, say a bank account balance. Okay, 310 00:14:55.240 --> 00:14:59.399 then that function returns an object containing two closures, a 311 00:14:59.440 --> 00:15:01.840 deposit function and a withdraw function. 312 00:15:01.960 --> 00:15:04.720 And because they were both created in the same outer scope, 313 00:15:04.759 --> 00:15:08.080 they share the exact same live reference to that one 314 00:15:08.159 --> 00:15:09.039 balance variable. 315 00:15:09.120 --> 00:15:13.000 Precisely, so, if the deposit closure adds money, the withdraw 316 00:15:13.039 --> 00:15:15.480 closure will instantly see the new balance because they are 317 00:15:15.480 --> 00:15:17.639 looking at the exact same space in memory. 318 00:15:17.799 --> 00:15:21.320 Wow. And because that balance variable was declared inside a 319 00:15:21.360 --> 00:15:25.000 function that has already returned, it is completely invisible to 320 00:15:25.039 --> 00:15:25.879 the rest of the program. 321 00:15:25.960 --> 00:15:26.840 Yep, untouchable. 322 00:15:26.879 --> 00:15:30.879 You get true encapsulation, true private state without needing traditional 323 00:15:30.879 --> 00:15:34.080 classes or complex architecture. The outside world can only touch 324 00:15:34.120 --> 00:15:37.200 the balance using the specific closures you explicitly handed back. 325 00:15:37.399 --> 00:15:41.480 It's brilliant, lightweight encapsulation. It's what makes JavaScript so unique. 326 00:15:41.639 --> 00:15:45.879 I love that. So closures are all about how functions 327 00:15:46.080 --> 00:15:50.879 capture their surrounding environment. But a function's identity itself changes 328 00:15:51.000 --> 00:15:53.120 entirely depending on exactly how you invoke it. 329 00:15:53.360 --> 00:15:54.720 Oh boy, Yeah, I'm talking. 330 00:15:54.559 --> 00:15:58.600 About the chameleon nature of functions and the dreaded this keyword. 331 00:15:58.480 --> 00:16:01.240 The binding of this is arguable the single biggest source 332 00:16:01.240 --> 00:16:03.000 of hair pulling in JavaScript history. 333 00:16:03.039 --> 00:16:04.639 I've lost a few hairs to it myself. 334 00:16:04.840 --> 00:16:08.720 We all have. And the confusion stems from treating JavaScript 335 00:16:08.720 --> 00:16:11.879 functions like they are static. They aren't. You have to 336 00:16:11.960 --> 00:16:15.120 understand the difference between calling a function, calling a method, 337 00:16:15.320 --> 00:16:16.559 and calling a constructor. 338 00:16:16.879 --> 00:16:19.159 But it can be the exact same block of code, 339 00:16:19.159 --> 00:16:21.200 literally the exact same text on the screen. 340 00:16:21.320 --> 00:16:23.879 I know, but the text doesn't matter. The syntax of 341 00:16:23.919 --> 00:16:27.279 the invocation changes everything. When you invoke code, the engine 342 00:16:27.320 --> 00:16:29.279 assigns a receiver to the keyword this. 343 00:16:29.600 --> 00:16:29.879 Okay. 344 00:16:30.080 --> 00:16:32.759 If you call it purely as a standard function like 345 00:16:32.919 --> 00:16:38.399 just hello, this binding defaults to pointing at the global object, 346 00:16:39.279 --> 00:16:42.240 or it becomes undefined. If you're operating in strict mode. 347 00:16:42.360 --> 00:16:46.200 That feels incredibly dangerous. If you accidentally use this thinking 348 00:16:46.240 --> 00:16:50.159 you are modifying a local property, you could be accidentally 349 00:16:50.159 --> 00:16:51.759 overwriting global variables. 350 00:16:51.879 --> 00:16:54.720 You absolutely could, and people do. Now. If you call 351 00:16:54.759 --> 00:16:57.320 it as a method, meaning it is attached to an 352 00:16:57.320 --> 00:17:01.840 object like user dot hello, then this is securely bound 353 00:17:01.879 --> 00:17:05.000 to the user object. The object itself becomes the receiver. 354 00:17:05.200 --> 00:17:06.839 Okay, that makes sense. And what if you call it 355 00:17:06.839 --> 00:17:09.480 with the new keyword like new hello. 356 00:17:09.599 --> 00:17:13.319 Then the function completely transforms into a constructor. The engine 357 00:17:13.359 --> 00:17:16.559 creates a brand new empty object on the fly and 358 00:17:16.680 --> 00:17:19.119 binds this to that new object for the duration of 359 00:17:19.119 --> 00:17:19.519 the function. 360 00:17:19.680 --> 00:17:22.440 Okay, here's my analogy for this chameleon behavior. Tell me 361 00:17:22.480 --> 00:17:23.000 if this works. 362 00:17:23.079 --> 00:17:23.519 Let's here it. 363 00:17:23.839 --> 00:17:27.200 A JavaScript function is like a highly versatile actor. If 364 00:17:27.200 --> 00:17:29.480 you call it normally, the actor is performing out on 365 00:17:29.519 --> 00:17:33.960 the street that's the global object. Anything goes usually chaos. Sure, 366 00:17:34.359 --> 00:17:36.240 if you call it as a method, they are performing 367 00:17:36.279 --> 00:17:38.839 on a specific set, like a living room. And if 368 00:17:38.880 --> 00:17:41.200 you use new the engine builds them a brand new 369 00:17:41.200 --> 00:17:42.839 stage right in front of your eyes. 370 00:17:42.960 --> 00:17:44.720 I think that's a perfect way to visualize it. 371 00:17:45.000 --> 00:17:47.559 But what if I want to guarantee where they perform? 372 00:17:48.000 --> 00:17:50.920 What if I extract a method and pass it around. 373 00:17:51.160 --> 00:17:55.440 Ah, that is where the danger peaks. Think about passing 374 00:17:55.440 --> 00:17:58.720 a method as a callback. You have user dot log in, 375 00:17:59.359 --> 00:18:01.839 and you pass that to a higher order function like 376 00:18:01.880 --> 00:18:03.039 an arraise dot for each. 377 00:18:03.160 --> 00:18:04.759 Happens all the time, right, But. 378 00:18:04.759 --> 00:18:07.599 When you hand user dot log in too for each, 379 00:18:08.200 --> 00:18:10.720 you aren't handing it the user object. You are just 380 00:18:10.839 --> 00:18:12.920 handing it the raw unattached function. 381 00:18:13.119 --> 00:18:15.559 Oh you strip away the receiver exactly. 382 00:18:15.759 --> 00:18:18.480 When four each eventually calls your callback, it calls it 383 00:18:18.519 --> 00:18:21.759 as a plane unattached function. The actor is back on 384 00:18:21.799 --> 00:18:22.200 the street. 385 00:18:22.319 --> 00:18:22.839 Oh wow. 386 00:18:22.960 --> 00:18:25.480 Yeah, So this suddenly points to the global object and 387 00:18:25.559 --> 00:18:29.480 your program crashes because the login properties it expects simply 388 00:18:29.480 --> 00:18:29.960 aren't there. 389 00:18:30.200 --> 00:18:32.720 So, if you, the listener, have ever passed a callback 390 00:18:32.759 --> 00:18:35.880 to a higher order function and watched your application basically 391 00:18:35.920 --> 00:18:38.400 catch fire, because this suddenly pointed to the wrong place. 392 00:18:38.839 --> 00:18:40.640 This is why you lost your receiver. 393 00:18:40.839 --> 00:18:41.039 Yep. 394 00:18:41.480 --> 00:18:43.559 So how do we fix the actor's contract? How do 395 00:18:43.640 --> 00:18:45.319 we stop them from going back to the street. 396 00:18:45.640 --> 00:18:48.759 You use the dot bind method. Calling dot bind on 397 00:18:48.839 --> 00:18:51.960 a function creates a new wrapper function that permanently locks 398 00:18:52.000 --> 00:18:52.599 down the receiver. 399 00:18:52.839 --> 00:18:55.480 So it gives the actor an ironclad contract to only 400 00:18:55.519 --> 00:18:58.680 perform in one specific theater, no matter who hires them 401 00:18:58.839 --> 00:19:01.359