5 ms·

This is very long, I’ve skimmed over the article. In the end, what I’m trying to understand, is what server components solve? Faster performance? Serving compil

This is very long, I’ve skimmed over the article. In the end, what I’m trying to understand, is what server components solve? Faster performance? Serving compiled app html on refresh? Why is it so much better than the old school hydration?

halflife 2y ago
@danabramov, would love to hear your stance on that
- danabramov 2y ago
  I didn't really attempt to motivate it from the practical standpoint in the article. The article aims to be more of "reinvent some old ideas from first principles, while explaining some novel parts" kind of thing. In particular, the callback to Miguel's article about async/await (https://tirania.org/blog/archive/2013/Aug-15.html https://tirania.org/blog/archive/2013/Aug-15.html) is intentional. I'd like to see some parts of my article as making a similar argument for 'use client' / 'use server' and the concept of first-class cross-environment references module system. And as for practical benefits, I think the main benefit is composition--ability to compose and weave Server/Client building blocks together. Of course there's been myriads of approaches to server/client apps but I've never seen anything with the same compositional properties as RSC. I think Sam's talk (https://www.youtube.com/watch?app=desktop&v=9CN9RCzznZc https://www.youtube.com/watch?app=desktop&v=9CN9RCzznZc) makes an amazing argument in favor of that viewpoint so I'll defer to him.
  - halflife 2y ago
    Thanks for the explanation, I understand that wasn’t the point of the article, I’m one step before trying to understand the motivation behind server components :) Obviously the technology is impressive, basically serializing code over the network. I’ll look into Sam’s talk.
mike1o1 2y ago
It might be a contrived example, but I found the example of syntax highlighting a blog post to be a good example of the benefits of RSC. If you hydrate on the client, you need to run the same exact code on the server and again on the client - however, that means you now might need to bring in a big syntax highlighting library to the client. With RSC all of that is done server side, so you don't need to ship the syntax highlighting library.
- halflife 2y ago
  That may be fine for static rendering libraries, but chart libraries for example would have to be pushed to the client as well. So it seems to me that the benefits are so small and network speeds today are so fast, that switching your entire backend stack for that is over complicated to the point of absurdity…
  - tshaddox 2y ago
    If it's a highly interactive chart that's displaying data small enough to easily be transmitted to and manipulated by the client, I agree that server components might not provide much benefit. The main use cases where server components provide a large benefit are: 1) Web sites with a very large number of components, but where any one page or session will use a very small (and unpredictable) subset of those components. These are things like social media feeds, where there could be many thousands of types of feed items, but most people will see just a handful of them. This is a tricky problem for code-splitting. 2) Components which require a lot of code to perform a render relative to the size of the rendered output. This is stuff like Markdown renderers and syntax highlighting. This benefit becomes even more obvious if the rendered output is mostly static but does contain some islands of interactivity.
    - halflife 2y ago
      Oh okay, example 1 makes it much more clear. Angular solves it very differently, fetching the data for the component, and the code to render it in parallel using @defer syntax. The client still renders it, but only on demand
dhucerbin 2y ago
Value proposition is “components for server”. But it’s worth to take a step back first. What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing. Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing. All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.
- halflife 2y ago
  Sorry, having trouble understanding the nuance of the auth example (FYI in react I have experience only in small scale projects). What’s the difference in classic client components having a root component validation auth?
  - dhucerbin 2y ago
    Sure! In some methods of authentication, like OpenID, not only your client need to present some UI, but also you need to prepare some endpoints on the backend to handle full flow of authentication. You probably also need to provide some parameters to those endpoints and methods inside. So again, you want to add one thing “auth”, but need to add code in multiple places in your app. Server components promise to encapsulate that. Idea is that you can grab a component from npm, and it will handle all of that orchestration for you, and component will be your only one interface, so all configuration can be passed as props (of course it will be taken from your env/secret). The promise is that you can encapsulate inside a components both client and server code.
    - halflife 2y ago
      Ok I probably need to read deeper into server components and look at specific implementation. Your saying that the same component, in the client makes sure that you have a live session (a la JWT in local storage), but in the backend checks that the client requests arrived with the correct credentials?

halflife 2y ago

@danabramov, would love to hear your stance on that

danabramov 2y ago
I didn't really attempt to motivate it from the practical standpoint in the article. The article aims to be more of "reinvent some old ideas from first principles, while explaining some novel parts" kind of thing. In particular, the callback to Miguel's article about async/await (https://tirania.org/blog/archive/2013/Aug-15.html https://tirania.org/blog/archive/2013/Aug-15.html) is intentional. I'd like to see some parts of my article as making a similar argument for 'use client' / 'use server' and the concept of first-class cross-environment references module system. And as for practical benefits, I think the main benefit is composition--ability to compose and weave Server/Client building blocks together. Of course there's been myriads of approaches to server/client apps but I've never seen anything with the same compositional properties as RSC. I think Sam's talk (https://www.youtube.com/watch?app=desktop&v=9CN9RCzznZc https://www.youtube.com/watch?app=desktop&v=9CN9RCzznZc) makes an amazing argument in favor of that viewpoint so I'll defer to him.
- halflife 2y ago
  Thanks for the explanation, I understand that wasn’t the point of the article, I’m one step before trying to understand the motivation behind server components :) Obviously the technology is impressive, basically serializing code over the network. I’ll look into Sam’s talk.

mike1o1 2y ago

It might be a contrived example, but I found the example of syntax highlighting a blog post to be a good example of the benefits of RSC. If you hydrate on the client, you need to run the same exact code on the server and again on the client - however, that means you now might need to bring in a big syntax highlighting library to the client. With RSC all of that is done server side, so you don't need to ship the syntax highlighting library.

halflife 2y ago
That may be fine for static rendering libraries, but chart libraries for example would have to be pushed to the client as well. So it seems to me that the benefits are so small and network speeds today are so fast, that switching your entire backend stack for that is over complicated to the point of absurdity…
- tshaddox 2y ago
  If it's a highly interactive chart that's displaying data small enough to easily be transmitted to and manipulated by the client, I agree that server components might not provide much benefit. The main use cases where server components provide a large benefit are: 1) Web sites with a very large number of components, but where any one page or session will use a very small (and unpredictable) subset of those components. These are things like social media feeds, where there could be many thousands of types of feed items, but most people will see just a handful of them. This is a tricky problem for code-splitting. 2) Components which require a lot of code to perform a render relative to the size of the rendered output. This is stuff like Markdown renderers and syntax highlighting. This benefit becomes even more obvious if the rendered output is mostly static but does contain some islands of interactivity.
  - halflife 2y ago
    Oh okay, example 1 makes it much more clear. Angular solves it very differently, fetching the data for the component, and the code to render it in parallel using @defer syntax. The client still renders it, but only on demand

dhucerbin 2y ago

Value proposition is “components for server”. But it’s worth to take a step back first. What is value proposition of react component in comparison to older “mvc-inspired” frameworks? That you can drop a component in your code and call it a day. Don’t need to wire up separate controllers, models and views. Just one thing. Now, if you want to add “auth” to your app (in react meta framework like next) you need to add component and probably add some routes and inject some middleware. With server components, you just add one component somewhere in the root of your app. Just one thing. All that over the wire format, suspended data fetching etc, are a result of solving that problem and keeping in mind that those components are slightly different. It takes more work, but in return we can interleave both types of components nearly freely.

halflife 2y ago
Sorry, having trouble understanding the nuance of the auth example (FYI in react I have experience only in small scale projects). What’s the difference in classic client components having a root component validation auth?
- dhucerbin 2y ago
  Sure! In some methods of authentication, like OpenID, not only your client need to present some UI, but also you need to prepare some endpoints on the backend to handle full flow of authentication. You probably also need to provide some parameters to those endpoints and methods inside. So again, you want to add one thing “auth”, but need to add code in multiple places in your app. Server components promise to encapsulate that. Idea is that you can grab a component from npm, and it will handle all of that orchestration for you, and component will be your only one interface, so all configuration can be passed as props (of course it will be taken from your env/secret). The promise is that you can encapsulate inside a components both client and server code.
  - halflife 2y ago
    Ok I probably need to read deeper into server components and look at specific implementation. Your saying that the same component, in the client makes sure that you have a live session (a la JWT in local storage), but in the backend checks that the client requests arrived with the correct credentials?