00:00 One problem that we've got now is, as I'm making this search, if I search for Salt Lake City, then I stop here. You notice I get these spikes for each one of these, and they're just spikes because I forgot to throttle again, and you will do this too. That's why I'm not going to start

00:16 the video over so that I do this right, because it's so easy to forget to throttle. But we're going to do that again. We'll do Salt, and actually, yeah, it didn't even catch my L because it was so bad. Look at how bad this is. What is going on? Why is it so bad? And it's

00:31 because that even though we prevented unnecessary recomputations, there are necessary ones, and it would be good for those ones to be faster. And so what we're going to do is we're going to assume that match sorter has been optimized as much as it possibly can, and we're just sending

00:48 way too much data to it for it to be of much use, or at least to be fast. The problem is that JavaScript is single-threaded, so if your JavaScript is evaluating, that means the browser can't do its repainting, and that's why React's concurrent features allows it to, like, okay, do a little bit

01:06 of work, now let the browser do a thing. Now a little more work, now let the browser. But the problem is match sorter is not hooked into that. It doesn't have any ability to say, okay, do a little searching, now pause. Now do a little more searching, now pause. That's just not a feature

01:21 of match sorter. Maybe it could be, but that is just the nature of the fact that the browser or JavaScript runtime environment is single-threaded. So if JavaScript's doing something, that means the browser can't do other things. So because of that, we end up with these janky

01:38 user experiences. But the cool thing is that the web platform has a mechanism whereby you can have extra JavaScript that runs over in a separate thread in what's called a web worker, and then the main thread, the thing that's keeping the user's experience as awesome as possible,

01:54 can go and communicate with that asynchronously and say, hey, I need you to do this thing, and then that thread can go do its thing, and while it's doing stuff, then the browser can be doing its thing and being really responsive to the user, and when this thing is done, then it can come back, and that's all. We can make that message communication promise-based,

02:12 and it actually ends up feeling like you're just making a network call, but it's all local to the device. It's pretty cool, and that's what we're going to do to free up our main thread here so that we're not seeing all this red nonsense. We're going to be using a feature called web worker.

02:27 This is a built-in supported feature into VEET, which we're using, and so by creating a new worker pointing to a particular module, we can, and actually our type is module, so we'll set it like this. By doing this, then we can create a web worker object, and then we can use the com link

02:48 API or module to make communicating across this asynchronous IO boundary as awesome as possible. Com link is really, really great, and it has a really good TypeScript support and everything as well, so I recommend that you actually have the documentation for both of these open

03:06 so that you can reference these as you're working through this. It is a little bit funny, especially that some of the TypeScript stuff is a little bit funny, but once you have it all set up and you're used to it, then it feels awesome. We're not actually going to leverage this yet. We're splitting this entire change into two steps because it's kind of big, so

03:26 the first part is just getting the web worker set up. When you're all done, the experience, the performance is all going to be exactly the same because you're not actually going to use the web worker yet. You're just going to set it up, and when you're done, you'll know that you have it right by having a filtercities.worker.ts thread in here, so you're in your sources tab.

03:45 You go over to the threads. If you've got it wide enough, it should show up on the right side here. Under threads, you'll see main. That's our main thread, and then you'll see the filtercities worker thread, and you can switch between those, and that'll control your debugger and all that stuff, but once you have that in place, then you'll know that you've got this work finished.

04:04 Before you do that, then you look at, actually, I'm not even seeing threads in here, maybe because there's only one, so you'll see that threads option. You'll see that we've got that filtercities thread in there. That's how you'll know that you're finished, and then we can move on to the next step to actually take advantage of this cool web worker that we set up. Let's go.