 So usually, we work in, like, intervals of years, and our current interval is about to end. It is. And we call it 2017. And so I was thinking, my next interval, what is it going to be about? Oh, it's going to be 2018. It is going to be 2018. It's like a plus one. And so I thought I would tell you my topic, and you can ask me questions. I would have to make, explain it to you, within two minutes. Within two minutes. Okay. Go. I'm aware of them. They're existing. They have been existing for a long time, but I think we need to start using them. Service workers. We've been using, I've been using them. Service workers is not, oh, so there's workers as a group, I guess, but I was talking about the web workers, the way of the web to giving you actual parallelism, like, true multithreading. A dedicated worker. A dedicated worker for your site. Okay. I think we should be looking at the native platforms like iOS and Android. And what they've been doing for quite a long time is doing only UI work on the main thread and putting everything else in a different thread. Okay. Right. And I mean, are we not doing that already? Some people are doing that already. I've done that. What I'm saying is I've done that already. I have done that already. There have been experiments, but I think it's everything but mainstream. And I think it needs to become mainstream because for the past couple years, the problem has always been jank. People doing too much JavaScript on the main thread and doing animations wrong and whatnot. And if we could just move the expensive JavaScript code to a different thread and have some really good patterns on how to still interact with the UI part of your app, you would be free to just, you know, write some blocking code, just do like some expensive JSON object serialization and it wouldn't really affect the performance of your app. The big part of the problem is that communication between the main page and the worker because that's so clumsy right now. It's post message. If you spend up a worker, you get post message, which you can send JSON objects at best. We have shared array buffer as well, which is a way you can reinvent all of the buffer overrun problems, but on the web. Which is great. I've been working on things to make it easier, which one of the things is com link, but I think there's lots of explorations to do. And it's definitely worth doing because it would just make the web feel good by default. It would be really nice. Less jank is a good thing. That is a good thing. And we're done!