Comment by ricardobeat | Hacker News Reader

Comment by ricardobeat | Hacker News Reader

Parent Full thread

> 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.

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.

> 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.

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.

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

The article is about a mostly-static marketing page.

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.

Reply on news.ycombinator.com