[nwienert]

Because they could have moved to a server based app not using RSC and seen similar gains, so the deception is they are trying to make it seem like RSC caused the gain (and riding on the back of a hyped new technology) whereas it's not really the case.

[madjam002]

But RSC is how you do server based apps with React, and they’re clearly sticking with React.

Sure you can render to static markup without RSC but then you have to do a lot of work to mix server/interactive client components, RSC makes it a lot easier to achieve “server based apps”.

It’s not a deceptive headline at all.

[nwienert]

I think it’s less work to just use static content in places and avoid having to learn a whole new model of rendering, routing, data fetching and a lot of rules than it is to have a traditional ssr app that compiles a few static pieces of content.

[ricardobeat]

RSC is how React figured out partial hydration. Before this, you would simply not move to a server-rendered app, as it was not worth it - the client bundle would stay the same and you're just increasing overhead.

[nwienert]

Not true in the slightest. A server rendered app would deliver your html up front so your app is completely rendered immediately, this has been common for many years now and improves performance quite a bit. Couple with sending some static parts that avoid JS which is quite doable you have 90 some % of the benefit in a simpler model. That’s also why more direct a comparison of a SSR app to a RSC app is interesting.

Partial hydration is great but it’s a shame React is coupling it to a whole new routing model, component model, server rendering, and with such complex rules on use and inherent waterfalls as a side effect. There’s no reason to. You can get partial hydration any number of ways and avoid all the complexity.

[ricardobeat]

> Couple with sending some static parts that avoid JS which is quite doable

If when you say "they could have moved to a server based app", you are implying that they could have done partial hydration easily some other way, that's a wild assumption. Until very recently partial hydration was not even on the table, as the community decided that downloading 10MB of JS for every website was fine, and not 'quite doable' for the majority of React apps; they are usually monolithic and built on top of frameworks that make it difficult. Not impossible (we were doing this back in 2016 with different tech), but very uncommon.

As I said above, this is exactly what RSC is solving for. It's not a new thing, but the first solution endorsed by React itself, and enabled them (and potentially all React apps) to gain SSR with partial hydration, reduce bundle sizes and actually improve load performance.

I'm not a big fan of any of this, just stating what it is. And I agree that it introduces monstrous complexity to an ecosystem that's already overflowing with it. Astro for example achieves this without introducing too many new concepts.

[nwienert]

Totally agree that partial hydration helps more than full hydration, but note that if you compared SSR vs RSC the charts they posted wouldn't look so impressive.

Maybe I was too strong worded, but the point stands that without making it really clear they are "skipping a generation" basically, it makes their comparison look extremely favorable, whereas RSC actually has a big overhead: it serializes all props and the entire tree that's not hydrated into an arbitrary serialization format that JS then needs to parse and hydrate. They actually are far from as zero-cost as other partial hydration methods. And if you had compared SSR vs RSC you'd see that the numbers don't actually improve so much.

So is it like 10/10 deceptive? No, but it's also a meme thats going around and not the first article to try and gain attention by conveniently leaving out of the title and most of the article that 80% of the gain they got was just going from client-only to server-rendered, and not actually RSC. I absolutely stand by it being deceptive, if only on a more annoying than actually harmful level. The graphs aren't comparing SSR to RSC, they're comparing the (comparatively much, much worse) client-only to RSC.

[ricardobeat]

> 80% of the gain they got was just going from client-only to server-rendered

That's what the article is about, isn't it? The gain comes from going from client-only to server-rendered. They did this using RSC. You could also do it using handlebars and jQuery if it was 2010 (with probably 100x better performance).

> if you had compared SSR vs RSC you'd see that the numbers don't actually improve so much

From the article: We saw a whopping 62% reduction in bundle size as well as as 63% improvement in Google's Speed Index. You would not get those gains by simply enabling SSR in an existing app, as the bundle size will remain the same. Unless.. you use Astro or RSC to enable SSR with partial hydration. Which is what they did.

[nwienert]

No, speed index would go up massively. A huge amount of lighthouse improves with server rendered content.

Likewise RSC is not nearly as free as other partial hydration methods. You send a full serialized copy of the tree and props over that has to be manually de serialized. This nullifies much of the benefit. Further, you still send the large (even larger now) copy of React. This is exactly why the comparison would be interesting to see, and why I brought up my concerns - it seems people are pretty under informed about this.

[Izkata]

> and not 'quite doable' for the majority of React apps

The article is about a mostly-static marketing page.

[ricardobeat]

I agree that's a bad choice, but it doesn't change the fact partial hydration was not available until very recently. Without Astro/RSC, you can either have SSG / SSR with large bundles, or an SPA with large bundles. These are the options.