WEBVTT 1 00:00:00.120 --> 00:00:02.720 Welcome to the deep dive. Think of this as your 2 00:00:03.120 --> 00:00:05.960 cheat sheet, maybe your shortcut to getting really well informed 3 00:00:05.960 --> 00:00:06.879 about important stuff. 4 00:00:07.000 --> 00:00:09.679 Yeah, we basically wade through all the information, find the 5 00:00:09.720 --> 00:00:12.279 core ideas, and bring back what you really need to know. 6 00:00:12.519 --> 00:00:14.119 Saves you time exactly. 7 00:00:14.560 --> 00:00:19.480 And today we are plunging into javascripts specifically for web developers. 8 00:00:19.760 --> 00:00:22.239 We've got a whole stack of resources here. 9 00:00:22.120 --> 00:00:25.960 We do, covering well everything from the real basic building 10 00:00:26.000 --> 00:00:28.480 blocks right up to the you know, the fancy new 11 00:00:28.519 --> 00:00:30.600 browser APIs and features just emerging. 12 00:00:30.960 --> 00:00:34.039 Right, So the mission for this deep dive pull out 13 00:00:34.039 --> 00:00:38.520 the essential concepts, maybe some surprising details about modern JS development. 14 00:00:38.240 --> 00:00:41.000 Give you a solid handle on it without you know, 15 00:00:41.079 --> 00:00:43.159 drowning you in every single tiny detail. 16 00:00:43.240 --> 00:00:46.920 Perfect. Okay, let's kick things off with something well fundamental. 17 00:00:47.200 --> 00:00:50.719 We always hear javascripts and ECMAScript toss around. What's the 18 00:00:50.759 --> 00:00:52.000 actual relationship there? 19 00:00:52.079 --> 00:00:56.479 Okay, good starting point. Think of ECMAScript as the official standard. 20 00:00:56.560 --> 00:00:59.159 It's the specificating like the rule book for how a 21 00:00:59.200 --> 00:01:03.280 scripting language should behave the rulebook okay in JavaScript? Well, 22 00:01:03.359 --> 00:01:06.519 JavaScript is the most well known language that actually follows 23 00:01:06.560 --> 00:01:09.079 those rules. It implements the ECMAScript standard. 24 00:01:09.319 --> 00:01:12.680 Ah, got it? So xmascript is the spec. JavaScript is 25 00:01:12.719 --> 00:01:14.280 the implementation. 26 00:01:14.040 --> 00:01:19.000 Exactly, and just like languages evolve, xmascript gets updated, new editions, 27 00:01:19.040 --> 00:01:22.439 come out S six, S twenty twenty, whatever, adding new features, 28 00:01:22.480 --> 00:01:26.200 refining things. JavaScript then usually catches up and implements those 29 00:01:26.280 --> 00:01:26.799 new features. 30 00:01:26.920 --> 00:01:30.040 Makes sense. So when we put JavaScript on a web page, 31 00:01:30.040 --> 00:01:32.719 we use the script tags. Our sources mentioned two main 32 00:01:32.760 --> 00:01:36.359 types these days, the old text JavaScript and the newer module. 33 00:01:36.680 --> 00:01:40.040 What's the key difference, right, So script type text JavaScript, 34 00:01:40.079 --> 00:01:43.000 that's the classic way. Code inside there runs in well 35 00:01:43.079 --> 00:01:44.840 basically the global scope for that script. 36 00:01:44.879 --> 00:01:46.120 Everything together pretty much. 37 00:01:46.200 --> 00:01:48.719 But script type module is different. I came with EES six. 38 00:01:48.920 --> 00:01:51.239 It tells the browser, hey, treat this code as a 39 00:01:51.280 --> 00:01:53.000 proper ECMAScript. 40 00:01:52.519 --> 00:01:53.920 Module and what does that let us do? 41 00:01:54.079 --> 00:01:56.840 That unlocks features like import and export, so you can 42 00:01:56.840 --> 00:02:00.599 break your code into smaller, reusable pieces, manage dependence the cleanly. 43 00:02:00.680 --> 00:02:03.640 It's a huge step up for organization and avoiding conflicts. 44 00:02:03.799 --> 00:02:05.840 Right, So it stops everything from just clashing in that 45 00:02:05.920 --> 00:02:10.120 one big global space, more organized, way, more organized. 46 00:02:09.919 --> 00:02:13.759 With separate offices communicating properly instead of one giant noisy room. 47 00:02:13.879 --> 00:02:18.759 Good analogy. Okay, moving into the code itself, comments, essential notes. 48 00:02:18.840 --> 00:02:19.000 Right. 49 00:02:19.439 --> 00:02:22.080 Our sources mentioned the C style comments. 50 00:02:22.280 --> 00:02:25.199 Yep, JavaScript uses the familiar SEA style you've got for 51 00:02:25.319 --> 00:02:28.120 single line comments. Anything after that on the line is ignored. 52 00:02:28.199 --> 00:02:30.000 And the multi line ones that's. 53 00:02:29.639 --> 00:02:31.599 To start and to end. You can put multiple lines 54 00:02:31.639 --> 00:02:34.439 of comments between those. It was a natural fit really, 55 00:02:34.439 --> 00:02:38.479 given JavaScript's influences and how common C style syntax was. 56 00:02:38.599 --> 00:02:42.520 Makes sense. Keep it familiar. Now, code structure curly braces. 57 00:02:42.560 --> 00:02:45.159 We use them everywhere, like with if statements. Are they 58 00:02:45.199 --> 00:02:47.439 just for looks or more fundamental? 59 00:02:47.479 --> 00:02:50.680 Oh, they're fundamental. They define code blocks. You can technically 60 00:02:50.719 --> 00:02:53.680 omit them for a single statement after an IF or 61 00:02:53.719 --> 00:02:56.199 a four like if condition do one thing. 62 00:02:56.319 --> 00:02:58.280 Yeah, I've seen that, but it's really. 63 00:02:58.080 --> 00:03:01.719 Really considered best practiced. Always use the curly braces. It 64 00:03:01.719 --> 00:03:04.479 makes the code much easier to read and prevents subtle 65 00:03:04.479 --> 00:03:07.520 bugs later if you add more statements to that block. 66 00:03:07.800 --> 00:03:12.639 Good advice, Always use the braces. Okay, Variables the heart 67 00:03:12.719 --> 00:03:15.199 of storing data. We've got the old var and the 68 00:03:15.240 --> 00:03:18.599 newer let and constant. Let's break down the key differences, 69 00:03:18.919 --> 00:03:21.520 scope hoisting all that stuff. 70 00:03:21.680 --> 00:03:25.400 Right, So var it's function scoped, meaning if you declare 71 00:03:25.439 --> 00:03:29.240 a var inside a function, it's known throughout that entire function, 72 00:03:29.360 --> 00:03:31.879 even inside nested blocks like ifts or loops. 73 00:03:32.039 --> 00:03:34.759 Okay, function scope and hoisting. 74 00:03:34.840 --> 00:03:37.599 Ye, var declarations are hoisted. That means the declaration part 75 00:03:38.000 --> 00:03:40.800 like varx is conceptually moved to the top of its 76 00:03:40.800 --> 00:03:41.919 function scope. 77 00:03:41.800 --> 00:03:43.560 Before the code runs just the declaration. 78 00:03:43.800 --> 00:03:46.520 Just the declaration the assignment x equals ten stays where 79 00:03:46.520 --> 00:03:49.120 you wrote it. This can lead to weird situations where 80 00:03:49.240 --> 00:03:51.719 you can use a variable before its declaration appears in 81 00:03:51.719 --> 00:03:54.479 the code, and it'll have the value undefined. 82 00:03:54.680 --> 00:03:56.479 And you can readeclare var variables too. 83 00:03:56.599 --> 00:03:59.080 Yep, you can write var myvar five and then later 84 00:03:59.159 --> 00:04:02.240 varivar ten in the same scope and JavaScript is fine 85 00:04:02.240 --> 00:04:03.759 with it, which can also cause confusion. 86 00:04:03.800 --> 00:04:06.680 Definitely sounds like it could. So how does let improve things? 87 00:04:07.000 --> 00:04:09.680 Let was introduced in e S six to fix these issues. 88 00:04:10.120 --> 00:04:12.879 The big change is block scope. A LET variable is 89 00:04:12.919 --> 00:04:15.919 only known within the specific block that curly braces words. 90 00:04:15.639 --> 00:04:18.360 Defined, So inside an if or a for loop, it 91 00:04:18.439 --> 00:04:20.399 only exists there exactly. 92 00:04:20.319 --> 00:04:23.920 Much more contained, much easier to reason about. It prevents 93 00:04:23.959 --> 00:04:26.560 accidental variable clashes between different parts of your code. 94 00:04:26.639 --> 00:04:30.319 That sounds way better. What about hoisting and redeclaration with let. 95 00:04:30.600 --> 00:04:34.839 Let declarations are also hoisted, but critically their initialization is not. 96 00:04:35.160 --> 00:04:38.120 This creates something called the temporal dead zone or TDZ. 97 00:04:38.600 --> 00:04:40.720 If you try to access a let variable before it's 98 00:04:40.720 --> 00:04:43.480 actual declaration line in the code, you get a reference there. 99 00:04:43.720 --> 00:04:46.839 Ah. Okay, so safer prevents using it before it's. 100 00:04:46.720 --> 00:04:49.839 Ready, right, and you cannot redeclare a let variable within 101 00:04:49.879 --> 00:04:52.399 the same scope. Yeah, if you try let x five 102 00:04:52.519 --> 00:04:55.079 let x bleeds ten in the same block, you'll get 103 00:04:55.120 --> 00:04:56.680 an error much stricter. 104 00:04:56.560 --> 00:04:59.839 Good and then const the name implies it can't be changed. 105 00:05:00.160 --> 00:05:03.319 Very similar to it's also block scoped has the TDZ 106 00:05:03.800 --> 00:05:05.800 and cannot be redeclared in the same scope. 107 00:05:05.959 --> 00:05:06.920 But the key difference. 108 00:05:07.199 --> 00:05:10.560 You must initialize a cost variable when you declare it 109 00:05:10.639 --> 00:05:14.480 like cost pi equals three point one four, and once assigned, 110 00:05:14.879 --> 00:05:17.839 you cannot reassign that variable to a different value. The 111 00:05:17.879 --> 00:05:19.439 binding is constant. 112 00:05:19.319 --> 00:05:23.040 So pi equals three later would cause an error exactly. 113 00:05:23.560 --> 00:05:26.199 But and this is important, if the const variable holds 114 00:05:26.199 --> 00:05:29.319 an object or an array, you could still change the 115 00:05:29.319 --> 00:05:31.800 contents of that object or array. You just can't make 116 00:05:31.839 --> 00:05:34.560 the variable point to a completely new object or array. 117 00:05:34.759 --> 00:05:38.480 Ah. Subtle but crucial distinctions. The variable binding is constant, 118 00:05:38.560 --> 00:05:42.439 not necessarily the value itself if it's an object precisely. 119 00:05:42.439 --> 00:05:45.560 And our sources mentioned a potential performance benefit to using 120 00:05:45.639 --> 00:05:48.240 let and const over var, because the engine has a 121 00:05:48.240 --> 00:05:50.240 better idea of how the variable will be used. 122 00:05:50.360 --> 00:05:53.800 Interesting worth keeping in mind. Now, naming these variables identifiers, 123 00:05:53.879 --> 00:05:55.000 are there strict rules? 124 00:05:55.199 --> 00:05:58.120 Yes, identifiers have to start with a letter, an underscore, 125 00:05:58.399 --> 00:06:00.879 or a dollar sign after the first character. You can 126 00:06:00.920 --> 00:06:02.319 also use numbers, okay. 127 00:06:02.480 --> 00:06:04.399 Any things you can't use definitely. 128 00:06:04.600 --> 00:06:09.199 You can't use JavaScript keywords like if, for function, let, const, var, 129 00:06:09.399 --> 00:06:12.959 et cetera. You also can't use reserved words words set 130 00:06:12.959 --> 00:06:16.639 aside for future use, and the literal values true, false, 131 00:06:16.680 --> 00:06:19.480 and null are also off limits as variable names. 132 00:06:19.720 --> 00:06:22.360 Makes sense, don't want to confuse the language itself. Okay, 133 00:06:22.399 --> 00:06:24.680 Let's talk data types the primitives first. These are the 134 00:06:24.759 --> 00:06:27.120 simple fundamental types, right, the. 135 00:06:27.079 --> 00:06:30.800 Basic building blocks. First up is number. This covers both 136 00:06:30.839 --> 00:06:34.439 integers and floating point numbers. JavaScript doesn't really distinguish between 137 00:06:34.480 --> 00:06:36.319 them internally in the way some other languages do. 138 00:06:36.399 --> 00:06:39.120 Some number okay, Any special ways to write. 139 00:06:39.000 --> 00:06:42.360 Numbers, Yeah, you can write integers in decimal obviously, but 140 00:06:42.399 --> 00:06:45.319 also binary using a zero B prefix, octal with a 141 00:06:45.439 --> 00:06:48.879 zero O prefix or just eleading zero in nonstrict mode, 142 00:06:48.920 --> 00:06:52.160 which can be confusing, and hexadecimal with zero. 143 00:06:52.120 --> 00:06:54.839 X hex is pretty common in web dev, very common. 144 00:06:55.000 --> 00:06:57.720 And within number you also have the special values nan 145 00:06:58.720 --> 00:06:58.959 not a. 146 00:06:59.040 --> 00:07:01.519 Number, which can confusingly is a number type right? 147 00:07:01.639 --> 00:07:04.639 Ah? Yes, type of nan returns number. It usually results 148 00:07:04.639 --> 00:07:07.759 from invalid math operations like zero zero, and you have 149 00:07:07.879 --> 00:07:09.319 infinity and into infinity. 150 00:07:09.480 --> 00:07:12.399 Okay, And what about really really huge numbers. 151 00:07:12.560 --> 00:07:15.720 That's where bigin comes in. It's a newer primitive type 152 00:07:15.720 --> 00:07:19.360 designed to handle integers larger than the maximum safe integer 153 00:07:19.439 --> 00:07:22.040 value for number, which is around two to the power 154 00:07:22.040 --> 00:07:23.199 of fifty three minus one. 155 00:07:23.279 --> 00:07:23.839 Wow. 156 00:07:24.279 --> 00:07:25.199 How do you create those? 157 00:07:25.360 --> 00:07:27.319 You append an end to the end of an integer 158 00:07:27.439 --> 00:07:30.600 literal like one, two, three, four five n or you 159 00:07:30.720 --> 00:07:31.680 use the big in function. 160 00:07:31.879 --> 00:07:33.120 Any gotcha's with big inn. 161 00:07:33.279 --> 00:07:36.120 Yeah. You can't mix biggest and number types in standard 162 00:07:36.120 --> 00:07:38.680 arithmetic operations directly. You have to convert them, and you 163 00:07:38.680 --> 00:07:41.360 can't use big in values with the built in math 164 00:07:41.399 --> 00:07:42.240 object methods. 165 00:07:42.439 --> 00:07:44.720 Good to know. Okay. Beyond numbers, we have. 166 00:07:44.759 --> 00:07:49.079 String represents text basically a sequence of sixteen bit Unicode characters. 167 00:07:49.480 --> 00:07:53.079 You can use single quotes, double quotes, or backticks to 168 00:07:53.160 --> 00:07:53.680 define them. 169 00:07:53.759 --> 00:07:55.759 Any difference between single and double quotes. 170 00:07:56.079 --> 00:08:02.000 Functionally no, it's mostly style preference, though enable template literals, 171 00:08:02.000 --> 00:08:05.040 which are super useful for embetting expressions directly into strings. 172 00:08:05.120 --> 00:08:07.399 Right with the syntax very handy. 173 00:08:07.439 --> 00:08:10.319 Next, boolean simple one can only be true or false, 174 00:08:10.639 --> 00:08:12.279 used all the time for conditional logic. 175 00:08:12.560 --> 00:08:16.519 Okay, and then null and undefined They seem similar but 176 00:08:16.600 --> 00:08:17.680 aren't quite. 177 00:08:17.360 --> 00:08:21.000 The same correct. Null is a primitive type that represents 178 00:08:21.000 --> 00:08:25.519 the intentional absence of any object value you explicitly set 179 00:08:25.600 --> 00:08:29.639 something to null. Undefined means a variable has been declared 180 00:08:29.920 --> 00:08:33.080 but hasn't been assigned of value yet. It's the default state. 181 00:08:33.480 --> 00:08:35.799 So null is I meant for this to be empty? 182 00:08:35.840 --> 00:08:38.559 And undefined is nobody put anything here yet? 183 00:08:38.720 --> 00:08:40.840 That's a good way to think about it. And finally, 184 00:08:40.879 --> 00:08:43.480 among the primatives, there's symbol symbols. 185 00:08:43.600 --> 00:08:45.799 These are unique identifiers right exactly. 186 00:08:45.919 --> 00:08:50.039 Symbol creates a unique, immutable primitive value. Even if you 187 00:08:50.080 --> 00:08:52.600 create two symbols with the same description, like symbol foo 188 00:08:52.639 --> 00:08:55.360 and simple foo, they are not equal. They're unique. 189 00:08:55.399 --> 00:08:56.120 What are they used for? 190 00:08:56.559 --> 00:08:59.120 Often? Uses keys for object properties when you want to 191 00:08:59.159 --> 00:09:03.320 avoid potential clashes with other properties or library code. There's 192 00:09:03.360 --> 00:09:06.519 also symbol dot four key, which creates or retrieve symbols 193 00:09:06.519 --> 00:09:09.600 from a global registry. So symbol dot for food. 194 00:09:10.000 --> 00:09:13.399 Interesting. Do they show up in normal object iteration? Not? 195 00:09:13.600 --> 00:09:16.320 Usually they aren't enumerated by four dot. In loops, you 196 00:09:16.360 --> 00:09:19.360 need specific methods like object dot get town property symbols, 197 00:09:19.720 --> 00:09:21.679 or reflect dot own keys to access them. 198 00:09:21.720 --> 00:09:23.559 Okay, and there are built in symbols. 199 00:09:23.240 --> 00:09:26.879 Too, Yes, well known symbols like symbol dot iterator, symbol 200 00:09:26.879 --> 00:09:29.799 dot replace, symbol dot search. These allow you to hook 201 00:09:29.840 --> 00:09:31.600 into fundamental language behaviors. 202 00:09:31.720 --> 00:09:35.360 That's a lot of primitives. Okay, let's talk operators doing 203 00:09:35.399 --> 00:09:39.200 things with these values basic math like and seem straightforward. 204 00:09:39.480 --> 00:09:43.039 But what about those bitwise operators? When do we use those? 205 00:09:43.240 --> 00:09:45.879 Right? So, multiplication and division have rules for nan and 206 00:09:45.960 --> 00:09:49.720 infinity like infinity zeros in NAN, but the bitwise operators 207 00:09:49.879 --> 00:09:53.720 and D or xo R not marriot left shift signed 208 00:09:53.759 --> 00:09:56.799 right shift, unsigned right shift. They operate directly on the 209 00:09:56.799 --> 00:09:58.440 binary representation of numbers. 210 00:09:58.440 --> 00:09:59.799 Lower level stuff, yeah. 211 00:09:59.639 --> 00:10:01.759 Very low level. You might use them for things like 212 00:10:01.919 --> 00:10:05.799 manipulating flags stored in a single number. Performance critical calculations, 213 00:10:05.799 --> 00:10:09.559 maybe graphics or network protocol work where you're packing data efficiently. 214 00:10:09.759 --> 00:10:12.120 So left shift multiplies by powers of two. 215 00:10:12.159 --> 00:10:15.120 Correct and preserves the sign signed right shift divides by 216 00:10:15.159 --> 00:10:18.240 powers of two, also preserving the sign. Unsigned right shifts 217 00:10:18.240 --> 00:10:20.840 also divides, but always fills with zeros on the left, 218 00:10:20.840 --> 00:10:24.279 so the result is always non negative. Not everyday tools 219 00:10:24.279 --> 00:10:26.240 for most web devs, but good to know they. 220 00:10:26.120 --> 00:10:30.879 Exist definitely now the sources mentioned the with statement sounds old, it. 221 00:10:30.799 --> 00:10:34.440 Is and definitely deprecated and forbidden in strict mode. Its 222 00:10:34.480 --> 00:10:38.399 idea was to shorten access to object properties like with 223 00:10:38.639 --> 00:10:42.960 document dot location instead of repeating document dot location. 224 00:10:43.360 --> 00:10:44.039 Why is it bad? 225 00:10:44.240 --> 00:10:46.799 It makes code really hard to understand because it's unclear 226 00:10:46.879 --> 00:10:50.200 where variables are coming from. Are they local, global, or 227 00:10:50.559 --> 00:10:53.840 from the with object And it kills performance because the 228 00:10:53.840 --> 00:10:55.639 engine can't easily optimize lookups. 229 00:10:55.799 --> 00:10:59.960 Avoid it good advice avoid with Okay, last fundamental strict 230 00:11:00.159 --> 00:11:02.399 mode you strict. Why should we use this? 231 00:11:02.720 --> 00:11:06.000 Strict mode is basically a way to opt into a cleaner, safer, 232 00:11:06.159 --> 00:11:08.919 less error prone version of JavaScript. You put the string 233 00:11:09.480 --> 00:11:11.799 you strict at the very top of a script or 234 00:11:11.840 --> 00:11:14.120 a function, and what does it do. It changes certain things. 235 00:11:14.120 --> 00:11:17.960 It turned some previously silent errors into throne errors. For example, 236 00:11:18.000 --> 00:11:20.879 assigning a value to an undeclared variable throws an error 237 00:11:21.120 --> 00:11:23.440 instead of implicitly creating a global variable. 238 00:11:23.480 --> 00:11:26.000 Ah. That's good. Helps catch typos exactly. 239 00:11:26.519 --> 00:11:30.320 It also prevents or throws errors for certain unsafe actions 240 00:11:30.720 --> 00:11:34.919 like deleting variables or functions. It bans the wis statement. 241 00:11:35.279 --> 00:11:38.679 It makes evil safer. It prevents using reserved words like 242 00:11:38.759 --> 00:11:40.960 evil or arguments as variable names. 243 00:11:41.039 --> 00:11:43.600 So it basically tightens up the rules and catches common 244 00:11:43.639 --> 00:11:44.799 mistakes pretty much. 245 00:11:45.000 --> 00:11:48.159 It helps you write more robust, maintainable code. It's highly 246 00:11:48.200 --> 00:11:50.200 recommended for all modern JavaScript development. 247 00:11:50.200 --> 00:11:53.240 Makes total sense like built in code review. Okay, let's 248 00:11:53.240 --> 00:11:57.240 switch gears to objects in a raise complex data first. 249 00:11:57.519 --> 00:12:02.159 That distinction primitive versus reference value. Why is this so critical? 250 00:12:02.440 --> 00:12:08.120 It fundamentally changes how you work with data. Primitive values, numbers, strings, booleans, 251 00:12:08.120 --> 00:12:10.600 et cetera. Are passed by value. When you assign a 252 00:12:10.600 --> 00:12:13.840 primitive variable to another, you're making a completely separate. 253 00:12:13.480 --> 00:12:15.320 Copy, independent copies, right. 254 00:12:15.519 --> 00:12:18.600 But reference values objects in a raise are passed by reference. 255 00:12:18.960 --> 00:12:21.960 When you assign an object variable to another, both variables 256 00:12:22.039 --> 00:12:24.679 end up pointing to the exact same object in memory. 257 00:12:24.399 --> 00:12:27.960 So changing the object through one variable affects the other absolutely. 258 00:12:28.159 --> 00:12:30.360 If you have OBJ one down a OBJ two dot 259 00:12:30.440 --> 00:12:32.320 day one and then you do OBJ two dot name 260 00:12:32.320 --> 00:12:34.519 aples a b UPJ one dot name will also be b. 261 00:12:35.120 --> 00:12:37.919 They're referencing the same underlying data structure. Understanding this is 262 00:12:37.919 --> 00:12:40.000 crucial for avoiding unexpected side effects. 263 00:12:40.000 --> 00:12:43.679 Definitely okay, So how do we figure out what type 264 00:12:43.720 --> 00:12:46.799 of data we have? Type of seems like the obvious choice, 265 00:12:46.840 --> 00:12:47.759 but it has quirks. 266 00:12:47.840 --> 00:12:51.480 It does type or for works great for primitives number, string, 267 00:12:52.000 --> 00:12:57.360 boolly and undefined symbol big int. It also correctly identifies 268 00:12:57.399 --> 00:12:58.799 functions returning function. 269 00:12:58.919 --> 00:13:00.759 But for objects, and as for. 270 00:13:00.799 --> 00:13:04.000 Most reference types, including regular objects in arrays, type offf 271 00:13:04.080 --> 00:13:07.879 just returns object, and confusingly, type of null also returns object. 272 00:13:08.039 --> 00:13:09.799 That's a long standing historical bug. 273 00:13:10.080 --> 00:13:12.559 So type of isn't always specific enough for objects. What 274 00:13:12.639 --> 00:13:13.360 else can we use? 275 00:13:13.600 --> 00:13:16.440 The instance of operator is often better for checking object types. 276 00:13:16.720 --> 00:13:18.879 You can do my array instance of array or my 277 00:13:19.039 --> 00:13:21.080 date instance of date to see if an object was 278 00:13:21.120 --> 00:13:24.200 created by a specific constructor or inherits from its prototype. 279 00:13:24.240 --> 00:13:27.960 Okay, instance of for more specific object checks now scope. 280 00:13:28.080 --> 00:13:30.639 How does JavaScript know which variable we mean when we 281 00:13:30.759 --> 00:13:33.200 use a name? The scope chain exactly. 282 00:13:33.799 --> 00:13:38.320 Scope determines where variables are accessible. JavaScript uses lexical scope, 283 00:13:38.559 --> 00:13:41.279 meaning scope is defined by where the code is physically written. 284 00:13:41.840 --> 00:13:44.519 When you use a variable, the engine first looks in 285 00:13:44.559 --> 00:13:47.639 the current innermost scope, and if it's not there, looks 286 00:13:47.639 --> 00:13:49.559 in the next scope outwards, then the next, and so 287 00:13:49.639 --> 00:13:53.440 on up the chain until it hits the global scope. 288 00:13:53.480 --> 00:13:56.440 This sequence of scopes is the. 289 00:13:56.360 --> 00:13:59.360 Scope chain, like nested boxes pretty much. 290 00:13:59.559 --> 00:14:01.559 If it which is the global scope and still doesn't 291 00:14:01.559 --> 00:14:04.600 find the variable, you get a reference error in strict mode. Anyway, 292 00:14:05.080 --> 00:14:07.759 looking up globals can be slightly slower than locals because 293 00:14:07.799 --> 00:14:11.039 the chain might be longer, but engines optimize this well. 294 00:14:11.240 --> 00:14:15.480 Okay. And memory management, JavaScript cleans up after itself with 295 00:14:15.559 --> 00:14:17.039 garbage collection. How does that work? 296 00:14:17.120 --> 00:14:21.480 Yes? JavaScript has automatic garbage collection PC. The engine tracks 297 00:14:21.480 --> 00:14:24.759 which objects are still reachable, meaning they can somehow be accessed, 298 00:14:24.960 --> 00:14:27.519 starting from the root objects like the global. 299 00:14:27.200 --> 00:14:30.039 Window object, so it traces all the references kind of. 300 00:14:30.360 --> 00:14:33.919 The most common algorithm is mark and sweep. The GC 301 00:14:34.000 --> 00:14:36.960 starts at the roots, marks all reachable objects, and then 302 00:14:37.039 --> 00:14:41.039 sweeps through memory reclaiming the memory used by any object 303 00:14:41.080 --> 00:14:42.080 that wasn't marked. 304 00:14:42.200 --> 00:14:44.840 So if nothing points to an object anymore, it gets 305 00:14:44.840 --> 00:14:45.399 swept up. 306 00:14:45.600 --> 00:14:50.039 Essentially, Yes, it's automatic, but not fool proof. You can 307 00:14:50.080 --> 00:14:53.279 still create memory leaks if you unintentionally keep references to 308 00:14:53.320 --> 00:14:56.240 objects you no longer need. And the timing of GC 309 00:14:56.440 --> 00:14:59.279 is nondeterministic. You don't control exactly when it runs. 310 00:15:00.000 --> 00:15:02.360 I know it's mostly handled, but leaks are still possible. 311 00:15:02.799 --> 00:15:05.759 All right, let's look at specific reference types. The basic object. 312 00:15:05.799 --> 00:15:07.840 It's more than just key value pairs, isn't it. 313 00:15:07.879 --> 00:15:11.279 Oh yeah. Object is the foundation for almost everything complex 314 00:15:11.279 --> 00:15:14.919 in JavaScript. It's a dynamic collection of properties where keys 315 00:15:14.960 --> 00:15:17.799 are usually strings or symbols, and values can be anything. 316 00:15:17.919 --> 00:15:20.879 We usually create them with object literals. It's the basis 317 00:15:20.879 --> 00:15:23.879 for prototype based inheritance, which is core to JS. 318 00:15:24.039 --> 00:15:27.159 The cornerstone, okay, an array. It's like a list, but 319 00:15:27.360 --> 00:15:29.320 more flexible than in some languages. 320 00:15:29.600 --> 00:15:33.600 Definitely. JavaScript arrays are ordered lists, but they're dynamic. They 321 00:15:33.600 --> 00:15:36.320 can grow and shrink, and importantly, they can hold elements 322 00:15:36.320 --> 00:15:38.919 of any data type mixed together. A single ray could 323 00:15:38.960 --> 00:15:41.679 have numbers, strings, objects, even other. 324 00:15:41.639 --> 00:15:43.080 Arrays very flexible. 325 00:15:43.159 --> 00:15:45.399 How do we make arrays. Literals are common. 326 00:15:45.600 --> 00:15:48.000 Literals are the most common and usually the best way. 327 00:15:48.120 --> 00:15:49.919 You can also use new array, but it has some 328 00:15:49.960 --> 00:15:53.240 weird behavior if you pass just one number argument. A 329 00:15:53.360 --> 00:15:56.279 ray out from is super useful for converting array like 330 00:15:56.360 --> 00:15:59.879 things like dom modalists or the argument's object or iter 331 00:16:00.360 --> 00:16:02.559 like sets or maps into real arrays. 332 00:16:02.679 --> 00:16:05.440 Array dot from some sandy and array dot from. 333 00:16:05.360 --> 00:16:08.080 Array does creates a new array with whatever arguments you 334 00:16:08.120 --> 00:16:10.000 pass it. A ray dot one two three gives one 335 00:16:10.000 --> 00:16:12.039 two three, and a ray of seven gives seven. It 336 00:16:12.080 --> 00:16:14.480 avoids the new array seven confusion, which creates an mpty 337 00:16:14.519 --> 00:16:15.399 array of length seven. 338 00:16:15.519 --> 00:16:20.879 Got it now changing array contents, dot fil sort, splice, 339 00:16:21.080 --> 00:16:21.720 What do these do? 340 00:16:21.799 --> 00:16:23.799 Phil Let's you set all or part of an array 341 00:16:23.799 --> 00:16:27.799 to a static value. Useful for initialization. Sort sorts the 342 00:16:27.879 --> 00:16:31.559 array in place than gotcha. By default, it sorts lexicographically 343 00:16:31.639 --> 00:16:32.639 like stringths. 344 00:16:32.240 --> 00:16:35.080 So one ten two would sort to one ten two exactly. 345 00:16:35.200 --> 00:16:38.399 For numeric sorting, you must provide a comparison function like 346 00:16:38.440 --> 00:16:41.399 ab equal ab for ascending order. 347 00:16:41.320 --> 00:16:44.039 Right always provide the compare function for numbers, and splice. 348 00:16:44.120 --> 00:16:46.639 Splice is the Swiss army knife. Let's remove elements in 349 00:16:46.679 --> 00:16:49.799 some elements or replace elements all of a specific index, 350 00:16:49.840 --> 00:16:53.320 modifying the original array directly. It's very powerful. Splice in 351 00:16:53.480 --> 00:16:55.039 x lead count outum one item. 352 00:16:54.919 --> 00:16:58.399 Two okay, modifies in place. What about finding things? Index 353 00:16:58.440 --> 00:17:00.200 of last and x xen inclusion. 354 00:17:00.000 --> 00:17:02.159 The first index of an item searching forwards last index 355 00:17:02.240 --> 00:17:05.079 yeah finds the last index searching backwards. Both return to 356 00:17:05.240 --> 00:17:07.759 nus one if not found, and both use strict equality 357 00:17:07.839 --> 00:17:10.400 and include just returns true or if false if the item 358 00:17:10.440 --> 00:17:12.880 exists in the array. Simpler if you don't need the index. 359 00:17:12.920 --> 00:17:15.839 It also uses strict equality index of and last index. 360 00:17:15.920 --> 00:17:18.559 Oves can take an optional second argument for the starting 361 00:17:18.599 --> 00:17:19.240 search position. 362 00:17:19.680 --> 00:17:24.240 Use includes for existence, check indexoflast, index of if you 363 00:17:24.279 --> 00:17:27.200 need the position. And reduce sounds like it boils an 364 00:17:27.240 --> 00:17:27.720 array down. 365 00:17:28.000 --> 00:17:31.279 It does. Reduce iterates through an array applying a function 366 00:17:31.279 --> 00:17:34.240 you provide to accumulate a single result. The function gets 367 00:17:34.279 --> 00:17:37.480 the accumulator, the current value, the index, and the array itself. 368 00:17:37.880 --> 00:17:40.440 You can some numbers, build an object, flatten an array 369 00:17:41.240 --> 00:17:45.039 really versatile. You usually provide an initial value for the accumulator. 370 00:17:45.200 --> 00:17:49.000 Powerful stuff, okay. Type dearrays in eight array float thirty 371 00:17:49.079 --> 00:17:53.519 two array. These sound specialized? Why use them over regular arrays. 372 00:17:53.519 --> 00:17:57.759 Performance, mainly when dealing with raw binary data. Regular rays 373 00:17:57.799 --> 00:18:01.519 are super flexible, but that flexibility has overhead. Type raise 374 00:18:01.559 --> 00:18:03.920 give you a direct fixed length view onto a chunk 375 00:18:03.920 --> 00:18:07.079 of binary memory an array buffer, where each element is 376 00:18:07.119 --> 00:18:10.759 known to be a specific numeric type like eight bit unsigned, editger, 377 00:18:10.880 --> 00:18:12.200 thirty two bit float, et cetera. 378 00:18:12.519 --> 00:18:15.880 So for things like graphics or processing audio data. 379 00:18:15.559 --> 00:18:19.960 Exactly WebGL web audio API manipulating file data read into 380 00:18:20.000 --> 00:18:22.960 an array buffer. They share many methods with regular arrays, 381 00:18:23.039 --> 00:18:25.799 map filter, etc. But they operate within the constraints of 382 00:18:25.799 --> 00:18:28.240 their type and fixed length. They also have methods like 383 00:18:28.359 --> 00:18:31.960 set for efficiently copying data in and subaray to create 384 00:18:32.000 --> 00:18:33.839 a new typed to array view over a portion of 385 00:18:33.839 --> 00:18:34.960 the same buffer. 386 00:18:34.720 --> 00:18:38.920 Efficient binary data handling and data view. How's that different? 387 00:18:39.240 --> 00:18:41.880 Data View also works on an array buffer, but it's 388 00:18:41.920 --> 00:18:44.799 even lower level. Instead of viewing the whole buffer as 389 00:18:44.839 --> 00:18:47.400 one type, data view lets you read and write different 390 00:18:47.480 --> 00:18:50.880 numeric types at any byte offset within the buffer. 391 00:18:50.680 --> 00:18:52.599 So you could read an eight bit in then a 392 00:18:52.720 --> 00:18:54.599 sixteen bit float from the same. 393 00:18:54.400 --> 00:18:57.759 Buffer precisely, and crucially, data view lets you control the 394 00:18:57.920 --> 00:19:01.559 endianness byte order big indian or little endian for multi 395 00:19:01.559 --> 00:19:04.640 byte types. This is essential when you're working with specific 396 00:19:04.680 --> 00:19:08.799 file formats or network protocols that dictate a particular byte order. 397 00:19:08.960 --> 00:19:12.880 So typed arrays for uniform numeric arrays. Data view for 398 00:19:13.000 --> 00:19:17.200 fine grained multi type endingess controlled access to binary data. 399 00:19:17.240 --> 00:19:18.000 That's a great summary. 400 00:19:18.079 --> 00:19:21.000 Okay, let's talk collections, map and set. How are they 401 00:19:21.000 --> 00:19:22.920