[mike1o1]

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]

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]

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]

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