WEBVTT 1 00:00:00.000 --> 00:00:02.799 All right, let's kick things off today. We're going deep 2 00:00:02.839 --> 00:00:07.080 on ACYNK JavaScript and how to write code that's not 3 00:00:07.160 --> 00:00:10.480 just functional but really sings performance wise. 4 00:00:10.759 --> 00:00:12.679 Yeah, we're talking speed exactly. 5 00:00:13.320 --> 00:00:16.039 And to guide us on this journey, we have Kyle 6 00:00:16.079 --> 00:00:19.600 Simpson's book You Don't Know JS, A sink and Performance. 7 00:00:19.800 --> 00:00:22.519 It's a fantastic resource, really digs deep. 8 00:00:22.640 --> 00:00:25.280 I've got to say this book was a game changer 9 00:00:25.320 --> 00:00:25.559 for me. 10 00:00:25.760 --> 00:00:26.399 Absolutely. 11 00:00:26.640 --> 00:00:29.600 When I first started with ACYNK JavaScript, it felt like 12 00:00:29.920 --> 00:00:31.760 I don't know, my brain was doing backflips. 13 00:00:31.839 --> 00:00:33.920 It's definitely a mind bender, especially that. 14 00:00:33.920 --> 00:00:37.920 Whole concept of later. You know how JavaScript handles things 15 00:00:37.960 --> 00:00:41.119 that can't happen right away right right. It's not exactly intuitive. 16 00:00:41.200 --> 00:00:44.079 It's like we assume later means well right. 17 00:00:44.000 --> 00:00:46.039 After now, Yeah, like step one, step two. 18 00:00:45.960 --> 00:00:48.479 But in javascripts later it's a whole different beast. 19 00:00:48.679 --> 00:00:51.039 So let's say you're making an ajax call to grab 20 00:00:51.079 --> 00:00:53.640 some data from a server. Okay, you write the code, 21 00:00:53.759 --> 00:00:55.799 you make the call, and then you try to log 22 00:00:55.840 --> 00:00:58.920 the data. You know, right after it seems logical, yeah, 23 00:00:58.960 --> 00:01:00.320 but then nothing. 24 00:01:00.159 --> 00:01:03.960 It's like where the data go proof vanish. The trick 25 00:01:04.079 --> 00:01:07.400 is we're thinking in a straight line but when you're 26 00:01:07.439 --> 00:01:11.879 dealing with things like timers, clicks, those AgeX responses, we're 27 00:01:11.879 --> 00:01:13.439 in the land of a synchronicity. 28 00:01:13.680 --> 00:01:16.439 Okay, so things are getting shuffled around exactly. 29 00:01:16.560 --> 00:01:18.760 Things don't always happen in a predictable order. 30 00:01:18.920 --> 00:01:21.879 So how does JavaScript decide what happens now versus what 31 00:01:21.959 --> 00:01:24.879 gets pushed to this mysterious later. 32 00:01:25.159 --> 00:01:27.719 It all comes down to this thing called the event loop. 33 00:01:27.959 --> 00:01:29.280 Okay, the event loop. 34 00:01:29.319 --> 00:01:31.760 Think of it like a queue, a never ending queue of. 35 00:01:31.719 --> 00:01:34.719 Tasks, all right. So each task gets. 36 00:01:34.480 --> 00:01:37.799 Its turn exactly, Each task gets its moment to run, 37 00:01:37.879 --> 00:01:40.280 and then boom, event loop moves on to the next one. 38 00:01:40.400 --> 00:01:43.280 It's like a very organized but super fast game of 39 00:01:43.400 --> 00:01:44.200 musical chairs. 40 00:01:44.560 --> 00:01:45.079 You got it. 41 00:01:45.280 --> 00:01:46.719 But what about set time out? 42 00:01:47.079 --> 00:01:47.519 Ah? 43 00:01:47.640 --> 00:01:50.200 Set time out is just like chuck the function into 44 00:01:50.280 --> 00:01:51.040 queue immediately. 45 00:01:51.239 --> 00:01:54.400 Not quite. It's more like it sets a timer okay, 46 00:01:54.439 --> 00:01:56.319 and when the timer goes off, it's like the function 47 00:01:56.480 --> 00:01:58.640 taps the event loop on the shoulder and says, hey, 48 00:01:58.680 --> 00:01:59.319 I'm ready now. 49 00:01:59.400 --> 00:02:02.200 Ah. It's like a reservation system for our code. 50 00:02:02.359 --> 00:02:03.920 I like that, a reservation system. 51 00:02:04.120 --> 00:02:06.400 But this brings up something that's always tripped me up. 52 00:02:06.840 --> 00:02:11.879 What's concurrency? Ah? Concurrency what happens when multiple things are 53 00:02:11.919 --> 00:02:13.199 trying to happen at the same time. 54 00:02:13.800 --> 00:02:17.159 It's a great question and important to remember. Even though 55 00:02:17.240 --> 00:02:21.439 JavaScript doesn't have traditional threads, we still have to deal 56 00:02:21.479 --> 00:02:25.400 with concurrency because at its heart it's single threaded. 57 00:02:25.680 --> 00:02:28.599 So it's like having one chef trying to cook multiple 58 00:02:28.599 --> 00:02:29.280 dishes at once. 59 00:02:29.560 --> 00:02:32.240 Exactly. They can only work on one thing at a time, 60 00:02:32.400 --> 00:02:34.479 but they've got to keep switching back and forth. 61 00:02:34.560 --> 00:02:36.719 So how do we make sure we're not creating kitchen 62 00:02:36.879 --> 00:02:38.639 chaos in our code? Right? 63 00:02:38.719 --> 00:02:40.000 We don't want everything burning? 64 00:02:40.199 --> 00:02:44.280 What happens when multiple functions try to access and you know, 65 00:02:44.560 --> 00:02:46.280 change the same data at the same time. 66 00:02:46.479 --> 00:02:49.120 It can get messy. But one way to manage this 67 00:02:49.240 --> 00:02:51.360 is using something called mutual exclusion. 68 00:02:51.560 --> 00:02:53.039 Mutual exclusion okay, like. 69 00:02:53.000 --> 00:02:55.159 Putting a lock on a shared resource. 70 00:02:54.759 --> 00:02:57.000 So only one function can access it at a time. 71 00:02:57.400 --> 00:02:59.319 You got it. You can think of it like a 72 00:02:59.400 --> 00:03:03.080 simple if statement that checks if a variable is being used. 73 00:03:03.479 --> 00:03:05.919 So it's like those occupied signs on a restroom stall. 74 00:03:06.080 --> 00:03:07.080 Perfect analogy. 75 00:03:07.080 --> 00:03:09.680 It's got a wait, it's turned exactly now, what about 76 00:03:09.680 --> 00:03:12.680 breaking down those tasks into smaller chunks? 77 00:03:12.800 --> 00:03:15.039 Ah, you're talking about cooperative concurrency. 78 00:03:15.240 --> 00:03:15.759 That's it. 79 00:03:15.759 --> 00:03:17.400 It's all about sharing the stage. 80 00:03:17.479 --> 00:03:20.879 So instead of one function hogging the event loop for ages, 81 00:03:20.919 --> 00:03:21.560 we break. 82 00:03:21.319 --> 00:03:24.159 It down right into smaller steps, give other functions a 83 00:03:24.240 --> 00:03:25.240 chance to run, so. 84 00:03:25.159 --> 00:03:28.520 We avoid that event loop traffic jam exactly. Okay. I 85 00:03:29.080 --> 00:03:31.719 gotta be honest, though, the fact that JavaScript can actually 86 00:03:31.759 --> 00:03:34.800 re order statements in my code, that kind of freaks 87 00:03:34.840 --> 00:03:35.159 me out. 88 00:03:35.280 --> 00:03:37.319 I get it. It feels like our code is being 89 00:03:37.400 --> 00:03:41.159 rearranged behind our backs, right, But remember the JavaScript engine, 90 00:03:41.639 --> 00:03:44.800 it's smart, okay. It's always looking for ways to optimize 91 00:03:44.840 --> 00:03:47.479 our code, and sometimes that means rearranging things as long 92 00:03:47.520 --> 00:03:49.000 as the final result is the same. 93 00:03:49.199 --> 00:03:51.159 So it's like having a super efficient editor. 94 00:03:51.400 --> 00:03:51.960 Exactly. 95 00:03:52.120 --> 00:03:54.319 They clean up our writing, but the meaning stays the 96 00:03:54.360 --> 00:03:56.680 same precisely. That makes me feel a bit better. 97 00:03:56.759 --> 00:03:58.639 Good, good, But it still. 98 00:03:58.400 --> 00:04:01.280 Makes it hard to picture, you know, what happens when, 99 00:04:01.680 --> 00:04:04.000 especially with all these asynchronous events flying around. 100 00:04:04.240 --> 00:04:08.120 It's true we're wired for linear thinking, but asynchronous code 101 00:04:08.159 --> 00:04:11.479 it's much more fluid. Ye think about trying to run 102 00:04:11.639 --> 00:04:14.280 errands and take phone calls at the same time. Oh yeah, 103 00:04:14.400 --> 00:04:16.879 You start one task, get interrupted by a call, go 104 00:04:16.959 --> 00:04:18.480 back to the task, interrupted again. 105 00:04:18.639 --> 00:04:22.759 It's impossible to plan everything perfectly in a straight line, exactly. 106 00:04:23.040 --> 00:04:25.079 You can't predict when those calls are going to come in. 107 00:04:25.319 --> 00:04:29.279 And I feel like that chaotic feeling gets amplified when 108 00:04:29.279 --> 00:04:31.000 we start using nested callbacks. 109 00:04:31.199 --> 00:04:33.519 Oh, nested callbacks they can get out of hand. 110 00:04:33.879 --> 00:04:36.519 It's like following a recipe where every step sends you 111 00:04:36.560 --> 00:04:38.600 on a wild goose chase for another ingredient. 112 00:04:38.800 --> 00:04:40.639 Right, You're jumping all over the place. 113 00:04:40.399 --> 00:04:41.800 And then you end up with a kitchen that looks 114 00:04:41.839 --> 00:04:42.839 like a tornado hit. 115 00:04:42.720 --> 00:04:46.160 It, exactly. And nested callbacks they can turn into a 116 00:04:46.199 --> 00:04:47.000 tangled mess. 117 00:04:47.319 --> 00:04:50.360 They make our code harder to understand, harder to debug, 118 00:04:50.800 --> 00:04:54.480 harder to maintain. Absolutely, which brings us to the well, 119 00:04:54.560 --> 00:04:58.560 the darker side of callbacks. Ooh, what's that the trust issues? 120 00:04:58.639 --> 00:05:00.839 Trust issues with a our own code. 121 00:05:01.120 --> 00:05:03.959 Yeah, shouldn't we be able to trust ourselves ideally? 122 00:05:04.120 --> 00:05:08.439 Yes, but remember in this acinc world, things get unpredictable. 123 00:05:09.120 --> 00:05:11.959 Even our own code can behave in ways we don't expect, 124 00:05:12.319 --> 00:05:14.839 especially when we're dealing with external libraries. 125 00:05:15.079 --> 00:05:16.279 Okay, you're losing me a little. 126 00:05:16.399 --> 00:05:19.600 Okay, imagine this. Yeah, you're adding a third party analytics 127 00:05:19.600 --> 00:05:22.639 tool to your website. You know, for tracking purchases. Okay, yeah, 128 00:05:22.680 --> 00:05:25.879 you hand over your purchase data to their library. Everything 129 00:05:25.920 --> 00:05:28.959 seems to be working fine. You pat yourself on the back. Job, 130 00:05:29.000 --> 00:05:33.040 well done, right, good job. Months later, your boss calls panicked. 131 00:05:33.560 --> 00:05:37.199 Oh no, a customer was charged five times for the 132 00:05:37.240 --> 00:05:37.959 same item. 133 00:05:38.199 --> 00:05:39.800 Oh that's a nightmare. 134 00:05:39.959 --> 00:05:42.959 It is. And after some frantic debugging, you find out 135 00:05:43.000 --> 00:05:47.160 that the analytics library was silently retrying the purchase callback 136 00:05:47.319 --> 00:05:49.639 multiple times, leading to those duplicate charges. 137 00:05:49.879 --> 00:05:51.720 It's like handing over the keys to your car and 138 00:05:51.759 --> 00:05:53.360 hoping they won't go on a joy ride. 139 00:05:53.560 --> 00:05:56.720 That's exactly the problem with callbacks, this inversion of control. 140 00:05:56.839 --> 00:05:59.639 We're handing over control and just hoping for the best. 141 00:05:59.800 --> 00:06:01.600 Right, But there's a better way. 142 00:06:01.720 --> 00:06:05.199 Tell me, there's a better way. Promises promises, those sound promising, 143 00:06:05.279 --> 00:06:06.040 They tell me more. 144 00:06:06.480 --> 00:06:10.319 A promise is essentially a contract for a future. 145 00:06:10.079 --> 00:06:12.879 Value, so like a guarantee in a way. 146 00:06:13.040 --> 00:06:14.920 Yeah, it's like saying, I promise to get back to 147 00:06:14.959 --> 00:06:16.800 you with the result of this operation. 148 00:06:16.600 --> 00:06:18.240 Whether it's a success or a failure. 149 00:06:18.439 --> 00:06:19.000 Exactly. 150 00:06:19.199 --> 00:06:23.160 So, instead of relying on this potentially flaky callback, we 151 00:06:23.240 --> 00:06:24.680 have a more structured approach. 152 00:06:25.240 --> 00:06:28.240 It's more reliable. I like it, and with promises, we 153 00:06:28.319 --> 00:06:30.399 keep control over the flow of execution. 154 00:06:31.000 --> 00:06:33.480 Okay, so we get to decide what happens next exactly. 155 00:06:33.839 --> 00:06:36.920 We define what should happen when the promise is fulfilled 156 00:06:37.360 --> 00:06:41.120 meaning the operation was successful, or rejected meaning there was 157 00:06:41.160 --> 00:06:41.720 an error. 158 00:06:42.000 --> 00:06:44.959 Okay, promises sound like a much safer bet they are. 159 00:06:45.279 --> 00:06:47.399 Could you walk me through an example. Maybe you know 160 00:06:47.439 --> 00:06:49.000 with our trustee ajax call. 161 00:06:49.279 --> 00:06:52.879 Absolutely, So instead of passing a callback function to that 162 00:06:52.920 --> 00:06:56.399 ajax call, we create a promise that represents the result 163 00:06:56.439 --> 00:06:59.839 of the request Okay, and then, using the then method, 164 00:07:00.240 --> 00:07:03.920 we specify what should happen when the promise resolves successfully. 165 00:07:04.040 --> 00:07:06.199 So it's like, if this happens, then do this you 166 00:07:06.279 --> 00:07:06.680 got it? 167 00:07:07.199 --> 00:07:09.439 And if something goes wrong, we can use the catch 168 00:07:09.480 --> 00:07:12.879 method to handle the error gracefully prevents our app from crashing. 169 00:07:13.000 --> 00:07:16.560 Okay. So promises make our asynchronous code more robust and 170 00:07:16.639 --> 00:07:20.959 predictable exactly. But what about when we have multiple asynchronous 171 00:07:21.000 --> 00:07:22.879 operations we need to do in sequence. 172 00:07:23.040 --> 00:07:26.120 Ah, That's where the magic of promise chaining comes in. 173 00:07:26.319 --> 00:07:28.639 Okay, promise chaining, you can use the. 174 00:07:28.519 --> 00:07:32.759 Then method to chain together a series of asynchronous steps. 175 00:07:32.480 --> 00:07:35.240 Each one depending on the one before it exactly. 176 00:07:35.279 --> 00:07:38.040 It's like a domino effect. Each step triggers the next. 177 00:07:38.160 --> 00:07:40.720 Okay, so instead of juggling all these promises at once, 178 00:07:41.319 --> 00:07:44.759 we create this smooth, organized flow precisely. 179 00:07:45.160 --> 00:07:47.839 It's all about creating a clear sequence of events. 180 00:07:48.079 --> 00:07:50.519 I love it. But what about situations where we have 181 00:07:50.720 --> 00:07:54.160 multiple promises happening concurrently, Like let's say we need to 182 00:07:54.160 --> 00:07:57.040 fetch data from multiple URLs at the same time. 183 00:07:57.240 --> 00:08:00.519 Ah, for that, we have promise at all at all. 184 00:08:00.680 --> 00:08:02.439 It's like waiting for all your friends to get ready 185 00:08:02.480 --> 00:08:03.560 before you head out for the night. 186 00:08:03.680 --> 00:08:05.839 You pass it in an array of promises. 187 00:08:05.439 --> 00:08:07.279 Yep, and it gives you back a new promise that 188 00:08:07.399 --> 00:08:09.560 resolves when all of those promises have resolved. 189 00:08:09.720 --> 00:08:13.079 So it's like okay, everyone's here, let's go exactly. 190 00:08:13.519 --> 00:08:17.839 And the best part is Promise all gathers all the 191 00:08:17.879 --> 00:08:21.399 results from those promises into a nice array, so you 192 00:08:21.399 --> 00:08:23.360 can work with the combined data easily. 193 00:08:23.959 --> 00:08:28.759 Okay, So promises can handle these complex scenarios, both sequential 194 00:08:28.920 --> 00:08:30.399 and concurrent. 195 00:08:30.399 --> 00:08:31.399 They're very versatile. 196 00:08:31.480 --> 00:08:34.679 I'm impressed I did. But earlier we were talking about 197 00:08:34.720 --> 00:08:38.519 you know, those nested callback nightmares with event handlers. Oh yeah, 198 00:08:38.759 --> 00:08:40.360 can promises help us out there too. 199 00:08:40.639 --> 00:08:43.360 They can, but we got to be careful. Okay, if 200 00:08:43.399 --> 00:08:46.080 we're not careful, we might just be trading one type 201 00:08:46.080 --> 00:08:47.279 of complexity for another. 202 00:08:47.480 --> 00:08:47.840 Okay. 203 00:08:47.960 --> 00:08:51.679 Creating a new promise chain inside each event handler can get. 204 00:08:51.480 --> 00:08:53.120 Messy, right, redundant code. 205 00:08:53.320 --> 00:08:54.519 It makes things hard to manage. 206 00:08:54.559 --> 00:08:59.039 So what's the secret to using promises effectively with event handlers. 207 00:08:59.559 --> 00:09:02.720 It's about shifting our perspective. Instead of creating a promise 208 00:09:02.840 --> 00:09:06.159 chain within the event handler, we can use observables. 209 00:09:06.360 --> 00:09:09.200 Observables. You mentioned those earlier. They sound pretty advanced. 210 00:09:08.919 --> 00:09:12.720 They're powerful, but the core concept is actually quite simple. Okay, 211 00:09:12.840 --> 00:09:15.399 think of an observable like a stream of events, right, 212 00:09:15.519 --> 00:09:18.399 like a flow of data exactly. You can subscribe to 213 00:09:18.399 --> 00:09:21.159 an observable and react to each event that comes through 214 00:09:21.159 --> 00:09:24.799 that stream using you guessed it promises. 215 00:09:25.000 --> 00:09:27.360 So it's like setting up a sensor. When it detects 216 00:09:27.360 --> 00:09:30.000 a change, it triggers a specific action. 217 00:09:30.440 --> 00:09:31.440 Perfect analogy. 218 00:09:31.679 --> 00:09:34.720 Okay, So observables sound like a whole other deep dive. 219 00:09:34.919 --> 00:09:37.399 We could definitely spend a whole episode on those, but. 220 00:09:37.440 --> 00:09:39.399 For now, let's move on to generators. 221 00:09:39.600 --> 00:09:42.879 Generators another powerful tool in our acinc toolkit. 222 00:09:42.960 --> 00:09:44.799 I gott admit I haven't quite wrapped my head around 223 00:09:44.799 --> 00:09:45.519 them yet. 224 00:09:45.559 --> 00:09:48.799 They're a really cool way to write asynchronous code that 225 00:09:48.919 --> 00:09:51.000 looks and feels synchronous. 226 00:09:51.039 --> 00:09:53.240 Wait, so you can write ACYNC code that looks like 227 00:09:53.240 --> 00:09:54.399 it's running in a stray line. 228 00:09:54.480 --> 00:09:57.759 You got it. Generators let you pause and resume execution 229 00:09:58.279 --> 00:10:00.240 using the yield keyword, like. 230 00:10:00.240 --> 00:10:01.759 Having a pause button for our code. 231 00:10:02.120 --> 00:10:05.480 Exactly. You can pause the execution, wait for an asynchronous 232 00:10:05.519 --> 00:10:08.600 operation to complete, and then resume right where you left off. 233 00:10:08.799 --> 00:10:11.080 Okay, my mind is blown. How does that even work? 234 00:10:11.240 --> 00:10:13.720 Imagine you have a function that needs to fetch data 235 00:10:13.759 --> 00:10:16.600 from a server. With a generator, you can yield control 236 00:10:16.639 --> 00:10:18.120 at the point where the request is made. 237 00:10:18.360 --> 00:10:21.799 Okay, Then when the data is available, you can resume 238 00:10:21.840 --> 00:10:23.480 the function right where you left off. 239 00:10:23.639 --> 00:10:26.399 So it's like breaking down a long task into smaller, 240 00:10:26.600 --> 00:10:28.720 more manageable chunks exactly. 241 00:10:29.200 --> 00:10:32.360 And the best part is the code inside the generator 242 00:10:32.679 --> 00:10:34.120 reads like a synchronous story. 243 00:10:34.600 --> 00:10:36.759 Okay, this is starting to make sense. Good, good, But 244 00:10:36.840 --> 00:10:41.320 how do we actually use this with real world asynchronous operations. 245 00:10:41.399 --> 00:10:43.919 That's where promises come back into play. Okay, we can 246 00:10:43.960 --> 00:10:47.279 create a promise that wraps the execution of the generator 247 00:10:47.600 --> 00:10:50.960 using yield to delegate to promises for asynchronous tasks. 248 00:10:51.000 --> 00:10:52.960 So we get the best of both worlds exactly. 249 00:10:53.480 --> 00:10:56.759 The synchronous looking code of generators combined with the trust 250 00:10:56.799 --> 00:10:58.360 and composability of promises. 251 00:10:58.480 --> 00:11:00.279 Wow, that's powerful. 252 00:11:00.440 --> 00:11:00.799 It is. 253 00:11:01.120 --> 00:11:03.080 But what about those of us who are still supporting 254 00:11:03.120 --> 00:11:06.000 older browsers, you know, the ones that haven't quit caught 255 00:11:06.039 --> 00:11:07.320 up to the whole generator scene. 256 00:11:07.360 --> 00:11:08.679 Don't worry, we got you covered. 257 00:11:08.799 --> 00:11:09.159 Okay. 258 00:11:09.240 --> 00:11:13.080 We can use a technique called transpiling, which basically translates 259 00:11:13.120 --> 00:11:17.240 our fancy ES six code, including generators, into code that 260 00:11:17.360 --> 00:11:18.879 older browsers can understand. 261 00:11:19.000 --> 00:11:22.080 So it's like a universal translator for JavaScript exactly. 262 00:11:22.080 --> 00:11:25.960 Okay, so we have options even when we're dealing with 263 00:11:25.159 --> 00:11:27.320 those legacy browsers. 264 00:11:27.440 --> 00:11:28.679 Always good to have options. 265 00:11:28.720 --> 00:11:30.759 I feel like we've covered so much ground already. 266 00:11:30.840 --> 00:11:33.240 We have, but we're just getting started. 267 00:11:33.360 --> 00:11:34.759 Oh man, my brain is already full. 268 00:11:34.840 --> 00:11:37.240 It's a lot to take in. But it's exciting stuff. 269 00:11:37.279 --> 00:11:38.879 It is exciting, and you know what, I'm ready to 270 00:11:38.960 --> 00:11:41.799 dive even deeper into the world of JavaScript performance. 271 00:11:41.879 --> 00:11:42.519 Let's do it. 272 00:11:43.200 --> 00:11:47.399 But first, a quick message from our sponsor, welcome back. 273 00:11:48.200 --> 00:11:51.600 Before the break, we were getting into generators and promises. 274 00:11:51.960 --> 00:11:56.480 How they can wrangle that asynchronous JavaScript all its quirks. Yeah, exactly. 275 00:11:57.080 --> 00:11:59.399 But there's another powerful tool we've got to talk about, 276 00:11:59.600 --> 00:12:01.879 and it's web workers. Ah. 277 00:12:02.320 --> 00:12:04.080 Yes, web workers. 278 00:12:04.120 --> 00:12:07.600 These things bring true parallelism to JavaScript. 279 00:12:07.720 --> 00:12:08.399 They really do. 280 00:12:08.600 --> 00:12:11.720 Imagine being able to run multiple pieces of code simultaneously, 281 00:12:12.080 --> 00:12:14.840 like having a whole team of chefs in the kitchen instead. 282 00:12:14.519 --> 00:12:16.480 Of just won much more efficient. 283 00:12:16.200 --> 00:12:18.960 Right, No more bottlenecks at the stove, exactly. But how 284 00:12:18.960 --> 00:12:21.159 do these webworkers actually work? Do they have their own 285 00:12:21.480 --> 00:12:23.639 like little JavaScript universe in a way. 286 00:12:23.799 --> 00:12:27.840 Yeah, Each webworker runs in its own isolated environment, separate 287 00:12:27.840 --> 00:12:28.720 from the main thread. 288 00:12:28.879 --> 00:12:31.000 So they're like independent apartments in a building. 289 00:12:31.159 --> 00:12:32.200 That's a good way to put it. 290 00:12:32.240 --> 00:12:35.240 They're separate, but can still, you know, communicate exactly. 291 00:12:35.279 --> 00:12:37.960 They communicate through a system called message passing. 292 00:12:37.759 --> 00:12:39.960 So it's like sending notes back and forth precisely. 293 00:12:40.159 --> 00:12:45.039 They can request data, send results, coordinate their actions all 294 00:12:45.080 --> 00:12:46.679 without stepping on each other's toes. 295 00:12:47.159 --> 00:12:51.159 Very civilized it is. But what about data structures? Can 296 00:12:51.200 --> 00:12:54.879 web workers access the same arrays and objects as the 297 00:12:54.919 --> 00:12:55.480 main thread? 298 00:12:55.799 --> 00:13:01.639 Not directly, no, okay, But there's this clever mechanism called transferable. 299 00:13:00.840 --> 00:13:03.279 Objects transferable objects. 300 00:13:03.360 --> 00:13:06.759 It allows them to efficiently share data instead of copying, 301 00:13:06.919 --> 00:13:09.600 which can be slow. They transfer ownership, so. 302 00:13:09.480 --> 00:13:11.559 It's like handing off a baton in a relay race. 303 00:13:12.039 --> 00:13:15.120 Perfect analogy. Only one runner can hold the baton at 304 00:13:15.120 --> 00:13:17.639 a time, but they pass it on smoothly. 305 00:13:17.399 --> 00:13:19.240 And that's way faster than making copies. 306 00:13:19.360 --> 00:13:22.200 Much faster, especially when you're dealing with large amounts of data. 307 00:13:22.279 --> 00:13:26.799 Okay, webworkers sound amazing, but are there any limitations? 308 00:13:26.960 --> 00:13:31.200 Yeah? Well, every superhero has their kryptonite, right. Webworkers don't 309 00:13:31.240 --> 00:13:33.519 have direct access to the dom. 310 00:13:33.600 --> 00:13:36.639 The dom, so they can't manipulate the user interface. 311 00:13:36.759 --> 00:13:41.799 They're more like behind the scenes heroes, crunching numbers, processing data, 312 00:13:41.840 --> 00:13:43.720 but not messing with the visual stuff. 313 00:13:43.879 --> 00:13:45.840 Got it. They're like the engine under the hood, not 314 00:13:45.919 --> 00:13:50.039 the flashy pain job exactly. But what about libraries in 315 00:13:50.159 --> 00:13:51.720 external code? Can they use those? 316 00:13:51.840 --> 00:13:55.600 Absolutely? Webworkers can use a function called import scripts to 317 00:13:55.679 --> 00:13:59.720 load external JavaScript files. It's like giving them a whole toolbox. 318 00:13:59.279 --> 00:14:01.399 So we could equip them for any task you got it. 319 00:14:01.600 --> 00:14:04.200 But what about older browsers, you know, the ones that 320 00:14:04.279 --> 00:14:06.200 haven't gotten the memo about web workers. 321 00:14:06.440 --> 00:14:10.200 For those cases, we have polyphills polyphills. They can emulate 322 00:14:10.240 --> 00:14:13.039 the behavior of webworkers even in those older browsers. 323 00:14:13.080 --> 00:14:15.159 It's like finding a vintage record player that can play 324 00:14:15.200 --> 00:14:16.960 modern digital music exactly. 325 00:14:17.039 --> 00:14:19.919 You get the functionality, even if the browser doesn't natively 326 00:14:19.960 --> 00:14:20.480 support it. 327 00:14:20.799 --> 00:14:24.480 That's awesome, it is. Okay, before we move on, I've 328 00:14:24.519 --> 00:14:27.919 heard this term thrown around SIMD. What is that all about? 329 00:14:28.240 --> 00:14:31.960 SIMD stands for single instruction multiple data. 330 00:14:32.440 --> 00:14:33.600 Okay, that sounds intense. 331 00:14:33.799 --> 00:14:36.480 It's a way to perform the same operation on multiple 332 00:14:36.519 --> 00:14:37.919 pieces of data at the same time. 333 00:14:38.159 --> 00:14:40.679 So it's like having an assembly line of robots, each 334 00:14:40.720 --> 00:14:43.440 one doing the same task but on a different item. 335 00:14:43.919 --> 00:14:47.799 Perfect analogy. It's mass production for data processing, very efficient, 336 00:14:48.039 --> 00:14:52.080 incredibly efficient, especially for computations involving large data sets. 337 00:14:52.159 --> 00:14:55.840 Okay, so we've got web workers for task parallelism, multiple 338 00:14:55.840 --> 00:14:59.000 workers tackling different tasks, right, and then sim and D 339 00:14:59.200 --> 00:15:03.000 for data parallel processing multiple pieces of data at once. 340 00:15:03.120 --> 00:15:06.200 You got it. It's all about finding the right tool 341 00:15:06.279 --> 00:15:10.080 for the job, leveraging parallelism to boost performance. 342 00:15:10.360 --> 00:15:13.120 This is blowing my mind. JavaScript can do so much 343 00:15:13.200 --> 00:15:14.159 these days. 344 00:15:13.960 --> 00:15:16.120 It really can, and it's only getting more powerful. 345 00:15:16.240 --> 00:15:18.720 So what's next on the horizon? For JavaScript performance. 346 00:15:18.840 --> 00:15:21.559 Well, there are some exciting proposals for new features that 347 00:15:21.600 --> 00:15:25.720 could bring even more parallelism to JavaScript, potentially allowing for 348 00:15:25.879 --> 00:15:27.440 direct threaded functionality. 349 00:15:27.559 --> 00:15:29.279 Wait direct threads in JavaScript. 350 00:15:29.320 --> 00:15:32.720 That's the idea. It's still early days, but the possibilities 351 00:15:32.759 --> 00:15:33.320 are huge. 352 00:15:33.600 --> 00:15:36.240 So we might be able to write truly parallel code 353 00:15:36.600 --> 00:15:39.440 without relying on web workers or SIMD. 354 00:15:39.960 --> 00:15:40.639 That's the goal. 355 00:15:40.679 --> 00:15:41.840 That would be a game changer. 356 00:15:42.039 --> 00:15:45.519 It would revolutionize how we approach JavaScript performance. 357 00:15:45.799 --> 00:15:48.679 This deep dive has been like a crash course in 358 00:15:48.840 --> 00:15:50.080 JavaScript optimization. 359 00:15:50.240 --> 00:15:52.039 We've covered a lot of ground. 360 00:15:51.759 --> 00:15:55.639 From the event loop, to concurrency, to web workers to SIMD. 361 00:15:55.960 --> 00:15:58.039 I feel like a JavaScript performance in ninja. 362 00:15:58.120 --> 00:16:00.360 You're well on your way, But how do. 363 00:16:00.320 --> 00:16:03.360 We actually know if our code is performing? Well? We 364 00:16:03.440 --> 00:16:06.559 can write all this async code, but how do we 365 00:16:06.600 --> 00:16:07.679 measure its efficiency? 366 00:16:07.799 --> 00:16:09.080 That's where benchmarking comes in. 367 00:16:09.159 --> 00:16:10.639 Benchmarking okay, it's the. 368 00:16:10.639 --> 00:16:14.679 Process of systematically measuring the performance of your code, seeing 369 00:16:14.679 --> 00:16:17.799 how long it takes to execute certain operations. It's like 370 00:16:17.879 --> 00:16:20.279 taking your code for a test drive on a racetrack. 371 00:16:20.480 --> 00:16:21.600 I love that analogy. 372 00:16:21.720 --> 00:16:23.000 You see how fast it can go. 373 00:16:23.399 --> 00:16:26.200 So how do we actually benchmark our JavaScript code? Do 374 00:16:26.240 --> 00:16:27.879 we need special equipment. 375 00:16:27.639 --> 00:16:30.840 Not necessarily. For simple tests, you can use the built 376 00:16:30.840 --> 00:16:34.799 inconsole dot time and console dot time end methods. 377 00:16:34.879 --> 00:16:37.000 Okay, so we can get a quick snapshot using the 378 00:16:37.039 --> 00:16:38.120 console exactly. 379 00:16:38.200 --> 00:16:40.519 It's like using a stopwatch to time your code. 380 00:16:40.639 --> 00:16:43.240 But I'm guessing there are more sophisticated tools out there 381 00:16:43.279 --> 00:16:44.559 for serious benchmarking. 382 00:16:44.840 --> 00:16:47.919 Absolutely. If you need more detailed measurements, you can use 383 00:16:47.960 --> 00:16:50.080 libraries like benchmark dot js. 384 00:16:50.200 --> 00:16:51.679 Benchmark dot js okay. 385 00:16:51.879 --> 00:16:55.159 It allows you to run multiple tests, collect data, even 386 00:16:55.279 --> 00:16:56.759 calculate the margin of error. 387 00:16:56.840 --> 00:16:58.919 Wow, margin of error. We're getting serious now. 388 00:16:59.120 --> 00:17:01.279 It's all about getting and reliable data so you can 389 00:17:01.279 --> 00:17:02.399 make informed decisions. 390 00:17:02.919 --> 00:17:06.079 So let's say we've run our benchmarks, we have some data. 391 00:17:06.599 --> 00:17:10.200 Now comes the fun part tuning. Where do we even begin. 392 00:17:10.599 --> 00:17:13.920 The first step is to identify the bottlenecks, the parts 393 00:17:13.920 --> 00:17:15.720 of your code that are slowing things down. 394 00:17:16.119 --> 00:17:18.079 So it's like finding the weak link in a chain. 395 00:17:18.319 --> 00:17:21.720 Precisely. Once you've found the bottlenecks, you can start exploring 396 00:17:21.759 --> 00:17:23.400 different optimization strategies. 397 00:17:23.480 --> 00:17:25.839 It's like being a code detective searching for clues to 398 00:17:25.880 --> 00:17:27.319 improve performance. 399 00:17:26.960 --> 00:17:29.680 Exactly, And just like a good detective, you need the 400 00:17:29.759 --> 00:17:31.039 right tools and techniques. 401 00:17:31.640 --> 00:17:35.200