[Bartkusa]

Each page is split into sections. Each section may wait for async data and API responses. When all the data arrives, the section is rendered as an HTML string.

The server streams each section's static HTML to the client as soon as it's ready, and after all prior sections are streamed.

The server also streams the async data to the browser. This avoids the latency of the client downloading some HTML, then downloading some JS, then making the requisite API calls for the page's data. (Think of it as a hacky version of HTTP Server Push.)

On the client-side, React and your JS are downloaded, React will recycle as much of the static DOM as possible (writing isomorphic JS isn't always easy), then take over and do its thing.

[hughbetcha]

> Each page is split into sections. Each section may wait for async data and API responses. When all the data arrives, the section is rendered as an HTML string.

Where are these waiting sections? On the browser client or the server?

Is the React code that is to be rendered on the browser served up automatically by ReactServer?

I'm sure it's a wonderful framework, but a diagram is really needed to understand any of this.

[patates]

So the client downloads the data twice? First embedded in HTML and then via an additional request?

[Bartkusa]

Good question. No, the data is downloaded only once.

The server tells the client what requests it's making on the client's behalf.

If the client's JS tries to make a request for a URL that's already in-progress, the client's React-Server code will skip the request and return a promise of the server's streamed response instead.

If the client's JS tries to make a request for something, and the server IS NOT already handling it, then the client will send out an HTTP request, and React-Server will step out of the way.