Unsurprisingly links (
<a> anchor tags) work as well in this condition. This isn't groundbreaking and every server-rendered library can benefit from this if they design their APIs to handle form posts. But it definitely makes for the jaw-drop demo.
Rich Harris, creator of Svelte, gave a very similar demo 4 days earlier. I'm not terribly surprised as this is core web fundamentals, and less popular frameworks have been doing the exact same thing for years even with React in tow.
For the majority of us, we might not need to cater to no JS. Ryan and Michael remind us repeatedly in their video that while this is really cool, the benefit is that by using the built-in platform mechanisms they can simplify the logic that you, the developer, need to write.
This announcement definitely was groundbreaking. Components that only render on the Server in React. These are being advertised as zero bundle-size components.
What does zero bundle-size actually mean? Well, it means that you aren't shipping these components with your bundle. Keep in mind, the rendered templates are making it to the browser eventually through a serialized format. You do save sending the React code to render it though.
Server components are stateless. Even so, there are big savings in not bundling for libraries like React whose code scales with template size as it creates each VDOM node one by one regardless. A stateless template in a framework like Lit or Solid, is just a one-line DOM template clone on top of the template itself which needs to be sent anyway.
A better perspective is to view this as a new type of integrated API. At minimum what you save here is the component-specific data-processing you do after you load some data. React Server components let you naturally create a per-component API that is perfectly tailored for that component's needs. That API just might contain some markup, so to speak.
This means no more Lodash or Moment in the browser. That is a huge win. But the real gain is how much easier it is to avoid performance cliffs. We could have already avoided sending most of this with our APIs, but we'd need to write those APIs.
What we get is a different way to do Code Splitting, and write our APIs. We are definitely shaving some weight, but zero bundle size isn't zero size.
A year or so ago Jason Miller, creator of Preact, was struggling to put a name on an approach to server rendering that had existed for years but no one was really talking about it. He landed on the Islands Architecture.
Astro is a multi-framework meta-framework built on top of this idea.
To be fair any 0kb JS app would have to function as separate pages. And with Astro 0kb is just a matter of not shipping client components. Progressive enhancement like described above is a natural addition.
Partial Hydration is a lot like the Island's architecture. The end result is Islands of interactivity.
The difference is the authoring experience. Instead of authoring a static layer and an Island's layer, you write your code like a single app more like a typical frontend framework. Partial Hydration automatically can create the islands for you to ship the minimal code to the browser.
Beyond the benefits in terms of DX from maintaining a single application, this opens up potential coordination of components. One such application is progressive(streaming) rendering.
In general, Partial Hydration extends the benefits of Islands giving the potential to treat your pages as single coordinated apps.
The real winner is the developer. All of these approaches give us the tools to simplify client-server interactions. That has been the real challenge as we attempt to move more to the server. And that is the really exciting part.