Means you can forget about library but your like button on your blog post still works. So, it's just about leaving behind what you don't need, basically. How do you measure an app's bundle size with the setup? That is a good question. So, there's a couple of things now. Right? So, we've got the client side, and, like, I say, the setup that we have in this workshop is super basic. Everything is still, like, individual. They're not bundled at all. So, how do you measure the client side bundle? Not easily at the moment. I guess you would just, like, sum up all of the scripts that you import at the client. I'm sure there's, like, Chrome tools which would help you with that. But you would definitely want to be doing this properly. If you're doing it for real in production. The other things to think about are also the size of the workers that you're producing. So, if you want these to be super performant and, like, globally distributed and all this sort of you want to generally minimize, like, them, too. So, it's quite nice that the region worker, the RSC thing is only focused on the server components and the global worker is only focused on well, in fact, that's probably the heaviest piece. Because it does both the turning client components into HTML but it's also got to understand, like, what it's getting back from RSC. So, this is probably the largest. RSC is probably the middle and then the client is probably the smallest which is nice for all of your users. It just means that you need to think about these. If you've got a massive app and you're trying to deploy it to a serverless provider like Cloudflare you might hit limits on how big of an app you can deploy. I think ours for workers is maybe 10 megabytes at the moment. So, if you're getting any bigger than that, you'd start to hit issues. But, yes, congrats. You've all made it through the hardest part. I hope that that was an exciting piece because it certainly was to me. You could hear it in my voice, I love this stuff. I think it's a pretty cool piece of technology. Server components, they're really pretty something. I still see the call to the JSON. I'm wondering how is that happening that I still have the index in my index.js, I still have the code to the todo. Ah, okay, yes, let's take a look. I do see that in the code for this global we are effectively packaging all the JS. I know exactly what you're talking about. Let me see if I can bring it up. Yeah, you shouldn't. So, the index.js that we had before, let's go back to the previous exercise. If we have a look at, if I just look at my built stuff, here I think it is. This is our full React app. It has everything in it, including, like you say, the await fetch. But if I have a look at the current one, I go to index.js, all we have here is the code to say, hey, go and get me these components. So, if we look at the app, like what it does, it loads index.js, which is that file we just saw. Then what's all this? It's going to be difficult to figure out what's, what, I think this is just oh, yeah, okay. So, it's loading like React libraries. React libraries, and then it's like localhost again. So, this is making a request with the text X component. This is the header saying, like, hey, go and get me this DOM. No, the issue was on my side, yeah, sorry. Okay, cool. So, yeah, all it has is the client component. Yeah, I forgot to restart the npm server, so it was still delivering the previous code, I guess. Cool. Like I say, the implementation we have at the moment is not, like, secure. I could still go to, like, todos.js and see it. We haven't done anything about, like, protecting our server side code. It just, like, I'm not running this in the current setup, which is nice. So, it's just proving out that you don't need to ship this code, because it's not needed. And there's a bunch of stuff that they're still playing around with in React core, like the new taint APIs and stuff, that's, like, ways to mark certain symbols in your code as, like, you absolutely cannot deliver this to the client or to the server, and to blow up the build if that was going to happen. So, that's still very much, like, in progress. So, work is still kind of feeling it out. Can you explain the browser script sections? Yes. So, this is another thing I kind of just tucked away, because I didn't think it deserved, like, highlighting. But let's have a look. Yeah. Browser React. So, in here, we have this kind of hack. And this is just saying, hey, like, load up, like, React experimental for me from this CDN. And also, hey, you need this other file, too. This is because we have fundamentally messed with how the client hydrates. So, before we were saying, hey, we're going to produce a server bundle, it's going to have everything in it, and we're also going to produce a client bundle that's going to have everything in it, and then the server is going to produce some HTML, and then once that's on the client, it's going to hydrate, it's going to redraw the entire page, and the client's going to take over. What we're doing here instead is a lot more piecemeal.