 So you're wearing a Christmas hat because it's Christmas. And as it's common in Christmas, we're going to talk about 12 things that we're excited about for the web. And I thought I would talk about architecture on the web. OK, two minutes. What is that? Architecture. That's buildings. It's nothing to do with the web, mate. You got confused. Well, the thing is that lots of other fields like enterprise engineering and gaming have these architectural patterns when they build really complex things. No, fields don't have architecture. You're thinking of cities. Software architecture, software engineering. You've come up with patterns to use to compose and combine things and to separation of concerns, all these things. And the web hasn't really done that. I mean, you could have done, but developers mostly are like, here's a little app that they built. Or they just throw things together and do most of the complex stuff in the back end. And I think it's time for the front of developers to have proper architecture in the front end code as well. But isn't this what all of the frameworks have been doing forever? Exactly. But I think these patterns should be exposed more to the developers themselves. For example, what I think that the web has an actor pattern where you have independent threads that are all running in a single-thread mode, but it communicates using post-package. That's pretty much what we have on the web. And that is called an actor pattern, but these two things have barely been combined on the web. And I think there's more patterns like this out there that haven't been applied to the web to make your front end architecture more manageable and nicer to work with. So what do we need to make this work, then? I think we already have everything that we need to make it work, but we haven't started using it. Like, we just need to look for the parents that game engineers use, that enterprise engineers use, and see if those are useful for us on the web and try to build things using it and just experiment. So getting stuff off the main threads except for the UI stuff is a set? For example, it's one thing I want to look into. And then how do you separate the concerns? What goes on to the off-thread, what stays on the main thread, and then how do you structure your code off-thread? It's not because that's just one big bolt of logic still. How do you compose those little bits and bobs? So in 10 seconds, what should be on the main thread? UI work. Right, in six seconds, what shouldn't be on the main thread? Not UI work. That is correct. Well done. Nailed it. I want to talk about weightless CSS. Weightless? That is one of the words I said. The other one is CSS. So CSS without weight? Yes, that is a good reversal of what I said. What is weight?