Bundle size is a huge part of the appeal of this. Right now if you use React for SSG in popular frameworks, loads of static content is duplicated in client bundles even though it’s completely useless for the client experience.

They cover some of this in the RFC. But I’ll use a site I’m working on as an example. There’s currently very little interactive content on the site, nearly everything is just Markdown content rendered to HTML and styled with CSS. But Next.js doesn’t know it’s static and sends it all again as React (well, Preact for my site) components. This doubles the weight of my pages on the wire, not to mention the performance impact of hydrating that static content.

I’ve been looking for weeks for a way to do what Server Components is doing, because while I love JSX for dev, that’s a really awful UX to foist on readers. There’s some prior art (search for Preact partial hydration if you’re interested), but it’s all very complex to set up. Having a first party reference solution will raise the bar significantly.

It's true that in the demo video, it's only called out that a third party dependency was removed from the client bundle. And it's true that these types of "infra" dependencies don't make up a large % of your codebase to begin with.

But there's another angle to consider. In thick client apps, product code (everything else) tends to take up the majority of the size of the client bundle. There's a real opportunity here to move some of that into Server Components which would help reduce that footprint significantly. For example consider the case of deeply wrapped components that ultimately render to a single <div>. Server Components could help remove that abstraction tax.

JSON bytes are cheaper than JS bytes, and it means if people want to write expensive components they can spend the processing power of their own servers instead of your phone.

Agreed, it's a strange bit to focus on. But it is true, even technically, bc of the way they go hand-in-hand: you don't need to send a "bundle", when you've done the rendering server-side. NextJS does a better job of making the case.

especially weird since you would use `date-fns` (vs. something like moment) specifically because it allows you to include only the functions that you require (via tree-splitting).

This is a bit of a convoluted example, but it also illustrates the point — I personally didn't know that! And I'm sure many people don't, either. The nice thing about Server Components is that for many use cases, you don't need to know the "right way" to import a library because it's simply not shipped to the client. And even the "right way" doesn't give you 0 bytes.