Comment by danabramov | Hacker News Reader

Comment by danabramov | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com