 So a problem with our search-as-you-type example app is that there's just a lot of different types of work happening here. And all of these different work have what we are calling grade deadlines. So for example, the user is typing in that search box. Their input has to be responsive. There's ongoing animations on the page. They have to render consistently and smoothly. And then there's the heavy lifting of fetching search results, post-processing, preparing, rendering these search results in time so that it's relevant to the user's typed inquiry. The difficulty is that it's hard for apps to balance these competing needs to reason about all these different deadlines and keeping everything meeting these timelines. So stepping back a bit, what we need here is some way to provide our chunks of work, our tasks, to a system that can hold them, say, in a task queue. And then this system can make good decisions about when to take tasks out of the task queue and execute them at an appropriate time based on everything that's going on. And this is the definition of a scheduler. Now while it's possible to build a scheduling system in JavaScript, they suffer from gaps, primarily because they don't have enough control on signals to properly control scheduling. So this is a very early sketch of what an API might look like. The key thing here is a set of global task queues targeting each priority level. And so this is really simple and straightforward compared to using a myriad different APIs. The second thing is we think it would be useful to have a notion of user-defined task queues, or virtual task queues. And this would give developers more control over managing a group of tasks and doing bulk operations, like updating priority, canceling all the tasks, or flushing the task queues if the app is going away. This is a link to our GitHub repo. Filing issues on the repo is a great way to get that feedback dialog going. If you're building a computer-aided design tool, a game, or doing encoding, these are great places to just start with threads. Same thing for AI, machine learning, crypto. If these are the types of things you're doing, you should start here. We've seen solutions to this in user land through libraries like comlink, greenlit, workerize, via.js. These all help coordinate messaging across boundaries by abstracting that post message using something called proxying. So messaging certainly improves over a post message. I'm sorry, proxying improves over a post message, but it comes with a number of downsides. Every method called to a proxied object incurs the cost of a thread hop. And this can come as a surprise to developers. Platform gaps can cause memory leaks in these APIs. These APIs don't really have a notion of a backing thread pool or a concept of managing threads and resizing the pool. Embedded libraries are not able to share the same thread or thread pool. And for complex APIs, it can be impractical to recreate this API surface. So this brings us to a new proposal we have that incorporates some of our learnings from other platforms. It lets developers avoid sending data back to the main thread. It lets you chain tasks together without data transfer and pay the return cost only once. It also minimizes thread hops using a built-in sticky thread pool. What we want is the experience that you see up here on the right. So this is a really early proposal. There's an implementation available in Chromium behind the experimental web platform features flag. And also, we have a polyfill and some source code and demos available at this GitHub repo. So the key thing to take away from this is workers might be able to make your rendering smoother, but they might do it at the expense of a bit of input delay. So we wanted to summarize when to use workers, but it turns out there's no perfect rubric for this. So there's a couple of hints you can use, though. If you have code that blocks for a long time, if you have code with small inputs and outputs, or something that follows the simple request response model, you might be in a position to start off with workers.