The RFC, which explains what these are without a video: https://github.com/reactjs/rfcs/blob/bf51f8755ddb38d92e23ad4...
Server Components are very different from what Next.js does today (traditional SSR). Here's a few differences:
* Server Components code is never sent to the client. By comparison, with traditional SSR all of the component code gets sent to the client anyway in the JS bundle.
* Server Components let you access the backend directly from anywhere in the tree. In Next.js, you can access the backend inside getServerProps(), but that only works at the top level page level, which means componentization is very limited. E.g. random npm component can't do that.
* Server Components can be refetched without losing the Client state inside of their tree. Because the primary transport is richer than HTML, we can refetch a server-rendered part (e.g. a search result list) without blowing away the state inside (e.g. the search input text, focus and selection).
That said, it's not a dig at Next.js -- the whole goal is to enable Next.js and similar frameworks to be much better.
Happy to answer specific questions!
Can this be run in any other back end other than Node since it only transmits a stream of serialized vdom?
Broadly speaking, it's a webpack plugin that finds all Client components and creates an id -> chunk URL map on the disk. And then the Node.js Loader that replaces imports to Client Components with access to to this map. You will be able to wire it up yourself, but there are other bits (like routing integration) so we're going to make it work in a framework like Next.js first. Then once there is a quality integration, you can copy how it's done in your custom setup.
>Can this be run in any other back end other than Node since it only transmits a stream of serialized vdom?
React components themselves are JS so we'd expect the backend to be in JS. (I mean, you could reimplement it in Rust or something, but then you can't easily move components to the Client and back.) There is no hard dependency on Node.js itself — as long as your JS environment has some sort of streams, we could make it work.
Certainly pre rendering would be more efficient too with these types of components so I imagine updates to hydration will be part of this.
Marked unstable because it was just recently added and is experimental. Per page is about the best Next can do, as it would need React itself to decide how to do this per component, which looks to be a big part of this new RFC.
Principal Skinner: Am I so out of touch? No, it's the children who are wrong.
I don't like the video format, but yours are always very enjoyable.