Thank you! I have very little patience for information delivered by video, it feels so inefficient compared to text in a lot of cases

Overall I agree with you (I'm the same) but some things are very hard to convey without seeing them in practice. Like I replied in the other comment, for those who don't want to watch the whole video, you'd still get a lot out of watching the demo (starting at 11:56).

Thanks Dan, sorry I missed your reply. Will check out the demo - sounds like a great new feature which I’m sure took a huge effort, so congratulations on the unveiling! Look forward to being able to use it :)

I had a quick look and that seems very convoluted. How do you decide which jsx goes to server and which to the client? Do you need to maintain jsx in both files? How to avoid duplication of code?

I haven't worked with server-side React, but my understanding is that you can parameterize a component to go one way or the other in a given context. The main value proposition (vs traditional server-side templating) is code-sharing

Thank you, I need to read more about that. Sounds promising.

Also worth noting: versions of this kind of thing have been around for years (see Next.js for a prominent example). It's unclear to me precisely how this announcement improves on the existing status-quo

I really recommend watching the talk and the demo for those who didn't. It's hard to convey the nuance without seeing it. If you want to skip the talk itself, just focus on the demo (timestamp 11:56).

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!

Is there any investigation planned or underway to pre compile these to some intermediate thing so non-node servers could hook into this? I’m thinking maybe some WASM interop off the top of my head perhaps. WASM is maturing fast and I’ve already seen demos where you can make network calls using a WASM interop server side.

Certainly pre rendering would be more efficient too with these types of components so I imagine updates to hydration will be part of this.

What will be the changes in bundling? Will it just be a simple webpack plugin or will more discipline be required?

Can this be run in any other back end other than Node since it only transmits a stream of serialized vdom?

>Will it just be a simple webpack plugin or will more discipline be required?

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.

Next.js does server rendering, but it doesn’t do this. Even with full static site generation, Next.js still sends the whole thing in a JS bundle to render on the client, even fully static components with no interactivity.

FWIW, you can disable this per page by adding `export const config = { unstable_runtimeJS: false}`.

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.

Thanks. I meant to mention this but forgot. And it’s certainly an improvement over “just schlep everything to the browser”, but it’s not a great solution for something like a long form static blog post with an interactive button in the site header.

Thank you, I clicked around everywhere trying to find something with a written explanation.

Same here - I will invest a great deal of effort in not having to watch a video, which increasingly makes me feel at odds with a large swathe of the engineer community.

Principal Skinner: Am I so out of touch? No, it's the children who are wrong.

On the plus side it's a pleasure to watch Dan Abramov's videos. I always feel I got a bit smarter afterwards.

Thank you for kind words! I felt very self-conscious about this one because there was no audience and recording at home was a lot harder than I thought. So it's nice to hear that you liked it.

Agree with the others, you're great at this.

I don't like the video format, but yours are always very enjoyable.

I thought you did a fantastic job, too.

I don't mind watching a video for a deep-dive, but I don't want to scan through a 60 minute video looking for a tl;dr

in case it helps anyone I went thru and timestamped the talk video and extracted some bits i figured worth emphasizing: https://twitter.com/swyx/status/1341124408060985345?s=20