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
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.
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.
>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.
