10 ms·

Everything About React Server Components

45 points by reimertz 6y ago

betoharres 6y ago
Is this basically the same idea that react native works? by sending and receiving JSON into the JS thread? but instead of a thread you just use a server, right?
Lx1oG-AWb6h_ZG0 6y ago
> At a high level, React Server Components are Components that can be rendered on the server and on the client. This is blatantly wrong. The RFC (and Dan Abramov’s video) make it clear that server components can only be run on the server: https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components https://github.com/josephsavona/rfcs/blob/server-components/...
- pdevr 6y ago
  Thanks for the RFC link. I guess you can have components and hooks to share stuff between server and client?
  - ameliaquining 6y ago
    If a component conforms both to the rules for server components (no interactivity) and to the rules for client components (no direct access to backend resources), then it can be used both as a server component and as a client component. This is useful for many purposes. But it is not true of server components in general.
me551ah 6y ago
It's funny how computers have become massively powerful with multiple cores and oodles of RAM , but still struggle with rendering html interfaces on the client. My machine can render Call of Duty at 60fps but will sometimes struggle to do that with websites.
- paulryanrogers 6y ago
  How much of CODs code is interpreted in real time? Because for the web it's usually 100% interpreted.
  - emerongi 6y ago
    The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies. We are using a document markup language to create interactive UIs. Which, for some crazy reason, has taken over the rest of the industry as well. I have a TV with a React UI, which takes around a second to respond to actions on my remote control. Decades ago, TVs were responsive, even though they had a minuscule amount of processing power compared to modern ones. You'd think that people would recognize that the web was not meant for what it is used today and would standardize on an alternative with similar benefits (easy debugging, quick feedback cycle, modern tooling) that would actually allow us to build proper interactive UIs, but apparently it is impossible to develop new software. Please, someone, kill HTML.
    - rualca 6y ago
      > The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies. Your personal assertion makes no sense. This is a purely technical problem, not a project management one. If you need to load a page and load a script and load data, and each load takes you around 100ms, then you don't change any of that with project management changes. Technical problems are addressed with technical solutions, and this article shows you one: prerender the content on the server-side to avoid having to wait for data fetches to get the initial page load to finish. > We are using a document markup language to create interactive UIs. Your remark makes absolutely no sense and has no bearing with either the problem domain or the discussion. The markup side of things is not a problem. Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all. Please bear in mind that you are posting comments on a discussion on, to put it clearly to you, procedurally generated websites. This is about a server-side rendering technique for React applications. In case you are unaware, React is a javascript frameworks that is used to generate and manage the DOM. The "markup language" side of things barely even registers as boilerplate to specify the entry point. It's the javascript script that you run after the HTML is loaded that assembles the document tree. > You'd think that people would recognize that the web was not meant for what it is used today Your comment makes zero sense, and reads like a non-sequitur rant.
swyx 6y ago
for those who want more detail on the capabilities RSCs unlock, I published a fully annotated walkthrough of the demo, based on my livestream with Lauren and Dan, on dev.to: https://dev.to/swyx/an-annotated-guide-to-the-react-server-components-demo-2a83 https://dev.to/swyx/an-annotated-guide-to-the-react-server-c...
dmix 6y ago
Sounds like what 37signals/basecamp has been pushing for as a model for a decade now. It took some time and flailing about in the community. But fortunately there was a relatively quick and massive structural change to programming large web front ends with compontent-based JS over the years. Much like Rails, the problem wasn't the language per-se, but a broad consensus regarding the best approach and having structure community wide helps solve a lot of problems. Now we finally have reached a pretty close consensus on the 'framework' side. Plus I'm also excited on the build systems side - as they are getting closer to just 'importing' other JS files instead of the endless magic of Webpack processors and similar hackery. So with that area finally quieting down, performance optimization around SSR and pushing as much to the server-side in general is also finally reaching maturity. This is a critical piece of the puzzle. And probably the last major hurdle for serious performant JS-heavy frontends. Heavily interactive web UIs are not going away no matter how many minimalist or anti-frontend-JS articles get posted on HN and elsewhere. Countless SaaS products depend heavily on stuff we've had on desktop for ages (most legit critiques apply to miss-use-cases, not inherent issues). And their potential for serious interfaces with well managed client-side state, consistent abstraction layers with components, clean UI logic, etc, instead of ungodly spaghetti messes that were difficult for dev teams to manage - ones that would changed dramatically every time a new dev/manager was hired - or simply trying to hack full-on Rails style MVC but purely client-side (see: backbone.js), is finally coming to and end. I'm personally a Vue, not React guy, but there's no question most advancements and experimentations happen in React's community first. Which a fine by me, as the good pieces always filter down to Vue quite quickly. SSR and deeper server integrations are clearly the way to go for any serious web app. The only downsides I've seen are they mostly JS server frameworks.
- bcherny 6y ago
  This is an interesting way to look at it! I think one missing piece that’s far from mature is data fetching. It’s really hard to get something working well at scale: - REST is simple, but you end up with serial waterfalls for complex fetches. - GraphQL avoids these waterfalls and lets you collocate declarative data with your components. This is great if your server layer supports it well. - You also need a way to fetch all descendants’ data high up the tree (to avoid serial fetches). Relay does this with a compilation step, and requires passing pointers back down the tree for runtime use. - Updating data (POST, PUT, Mutations) is super tricky to do in a way that keeps data consistent, avoids over-fetching, handles exceptions and idempotence and retries right, etc. I wish there was a standard here, but I think we’re still pretty far from it.
samirsd 6y ago
does this work with python backend frameworks like django or flask, or is it strictly node?
- kaleidawave 6y ago
  Just node. As React server components are JS and the React server runtime is written for node

45 points by reimertz 6y ago

Is this basically the same idea that react native works? by sending and receiving JSON into the JS thread? but instead of a thread you just use a server, right?

Lx1oG-AWb6h_ZG0 6y ago

> At a high level, React Server Components are Components that can be rendered on the server and on the client. This is blatantly wrong. The RFC (and Dan Abramov’s video) make it clear that server components can only be run on the server: https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components https://github.com/josephsavona/rfcs/blob/server-components/...

pdevr 6y ago
Thanks for the RFC link. I guess you can have components and hooks to share stuff between server and client?
- ameliaquining 6y ago
  If a component conforms both to the rules for server components (no interactivity) and to the rules for client components (no direct access to backend resources), then it can be used both as a server component and as a client component. This is useful for many purposes. But it is not true of server components in general.

me551ah 6y ago

It's funny how computers have become massively powerful with multiple cores and oodles of RAM , but still struggle with rendering html interfaces on the client. My machine can render Call of Duty at 60fps but will sometimes struggle to do that with websites.

paulryanrogers 6y ago
How much of CODs code is interpreted in real time? Because for the web it's usually 100% interpreted.
- emerongi 6y ago
  The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies. We are using a document markup language to create interactive UIs. Which, for some crazy reason, has taken over the rest of the industry as well. I have a TV with a React UI, which takes around a second to respond to actions on my remote control. Decades ago, TVs were responsive, even though they had a minuscule amount of processing power compared to modern ones. You'd think that people would recognize that the web was not meant for what it is used today and would standardize on an alternative with similar benefits (easy debugging, quick feedback cycle, modern tooling) that would actually allow us to build proper interactive UIs, but apparently it is impossible to develop new software. Please, someone, kill HTML.
  - rualca 6y ago
    > The technical reasonings don't matter. It is a reflection of the failure on the part of software engineers, product managers and standards bodies. Your personal assertion makes no sense. This is a purely technical problem, not a project management one. If you need to load a page and load a script and load data, and each load takes you around 100ms, then you don't change any of that with project management changes. Technical problems are addressed with technical solutions, and this article shows you one: prerender the content on the server-side to avoid having to wait for data fetches to get the initial page load to finish. > We are using a document markup language to create interactive UIs. Your remark makes absolutely no sense and has no bearing with either the problem domain or the discussion. The markup side of things is not a problem. Parsing and rendering HTML is not a problem. HTML does not even feature in this discussion at all. Please bear in mind that you are posting comments on a discussion on, to put it clearly to you, procedurally generated websites. This is about a server-side rendering technique for React applications. In case you are unaware, React is a javascript frameworks that is used to generate and manage the DOM. The "markup language" side of things barely even registers as boilerplate to specify the entry point. It's the javascript script that you run after the HTML is loaded that assembles the document tree. > You'd think that people would recognize that the web was not meant for what it is used today Your comment makes zero sense, and reads like a non-sequitur rant.

swyx 6y ago

for those who want more detail on the capabilities RSCs unlock, I published a fully annotated walkthrough of the demo, based on my livestream with Lauren and Dan, on dev.to: https://dev.to/swyx/an-annotated-guide-to-the-react-server-components-demo-2a83 https://dev.to/swyx/an-annotated-guide-to-the-react-server-c...

dmix 6y ago

Sounds like what 37signals/basecamp has been pushing for as a model for a decade now. It took some time and flailing about in the community. But fortunately there was a relatively quick and massive structural change to programming large web front ends with compontent-based JS over the years. Much like Rails, the problem wasn't the language per-se, but a broad consensus regarding the best approach and having structure community wide helps solve a lot of problems. Now we finally have reached a pretty close consensus on the 'framework' side. Plus I'm also excited on the build systems side - as they are getting closer to just 'importing' other JS files instead of the endless magic of Webpack processors and similar hackery. So with that area finally quieting down, performance optimization around SSR and pushing as much to the server-side in general is also finally reaching maturity. This is a critical piece of the puzzle. And probably the last major hurdle for serious performant JS-heavy frontends. Heavily interactive web UIs are not going away no matter how many minimalist or anti-frontend-JS articles get posted on HN and elsewhere. Countless SaaS products depend heavily on stuff we've had on desktop for ages (most legit critiques apply to miss-use-cases, not inherent issues). And their potential for serious interfaces with well managed client-side state, consistent abstraction layers with components, clean UI logic, etc, instead of ungodly spaghetti messes that were difficult for dev teams to manage - ones that would changed dramatically every time a new dev/manager was hired - or simply trying to hack full-on Rails style MVC but purely client-side (see: backbone.js), is finally coming to and end. I'm personally a Vue, not React guy, but there's no question most advancements and experimentations happen in React's community first. Which a fine by me, as the good pieces always filter down to Vue quite quickly. SSR and deeper server integrations are clearly the way to go for any serious web app. The only downsides I've seen are they mostly JS server frameworks.

bcherny 6y ago
This is an interesting way to look at it! I think one missing piece that’s far from mature is data fetching. It’s really hard to get something working well at scale: - REST is simple, but you end up with serial waterfalls for complex fetches. - GraphQL avoids these waterfalls and lets you collocate declarative data with your components. This is great if your server layer supports it well. - You also need a way to fetch all descendants’ data high up the tree (to avoid serial fetches). Relay does this with a compilation step, and requires passing pointers back down the tree for runtime use. - Updating data (POST, PUT, Mutations) is super tricky to do in a way that keeps data consistent, avoids over-fetching, handles exceptions and idempotence and retries right, etc. I wish there was a standard here, but I think we’re still pretty far from it.

samirsd 6y ago

does this work with python backend frameworks like django or flask, or is it strictly node?

kaleidawave 6y ago
Just node. As React server components are JS and the React server runtime is written for node