Live data from Hacker News

React Server Components made our site a lot faster

frigade.com

41–50 of 62 posts

Re: React Server Components made our site a lot faster

#41

Wow there's a lot of negative comments here on such a simple post along the lines of "Hey we adopted this new version of this library and it boosted our site performance x%". I think the move React is making to embrace the server side is a great thing. It shows we pushed really hard in one direction, made great progress in building a simple and easy-to-grok front end JS library in doing so, but in the end found that…

It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space.

Then, hey, it turns out those idiot backend devs that were so looked down upon may actually have known what they were doing after all.

There's also the bit where RSC seems wonderful if all you know is react but seems very mediocre if you've any significant experience with any of a number of other backend stacks

Re: React Server Components made our site a lot faster

#42

That’s great. What if I don’t want to write a whole new NodeJS backend just to support SSR, when the existing backend with all our APIs that we already wrote is a Spring Boot service? I’ve looked at Nashorn and then Graal to do this, but couldn’t find widely supported resources that work well and snap right in. Anyone in the same boat that has had success?

Pick up unpoly, HTMX, Hotwire, or some other hypermedia oriented library and have the Spring Boot server start rendering HTML instead of JSON

HTML templating works great, it's battle tested, typically still blows away RSC performance, and you get to keep all your mature domain logic and data layers while being able to deliver great UX with minimal client code

Re: React Server Components made our site a lot faster

#43

Wow there's a lot of negative comments here on such a simple post along the lines of "Hey we adopted this new version of this library and it boosted our site performance x%". I think the move React is making to embrace the server side is a great thing. It shows we pushed really hard in one direction, made great progress in building a simple and easy-to-grok front end JS library in doing so, but in the end found that…

It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space. Then, hey, it turns out those idiot backend devs that were so looked down upon may actually have known what they were doing after all. There's also the bit where RSC seems wonderful if all you know is react bu…

I have yet to meet a frontend dev who called a backend dev an idiot. I have met plenty of backend devs who have indirectly called frontend devs idiots.

Re: React Server Components made our site a lot faster

#44

Earlier quoted context omitted.

It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space. Then, hey, it turns out those idiot backend devs that were so looked down upon may actually have known what they were doing after all. There's also the bit where RSC seems wonderful if all you know is react bu…

I have yet to meet a frontend dev who called a backend dev an idiot. I have met plenty of backend devs who have indirectly called frontend devs idiots.

I have to agree on this. But also anyone who calls anyone else an "idiot" for how they code is doing it wrong™. We can learn from what eachother thrive in. For backend, it's usually data structures, databases, performance, etc. while on the frontend it's creating visually appealing UIs that feel good to interact with and both of those sides of web dev act to bring people into what we create time and time again. So when backend devs get mad when frontend devs say "Hey, maybe backend isn't so bad after all", that feels backwards.

Re: React Server Components made our site a lot faster

#45

Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. This has nothing to do with RSC, and @dang /moderators should probably change the headline. "Moving from a client-side app to a server app (using React Server Components) made our site faster" is very unsurprising, not very interesting (what would be interesting is comparison…

I think their headline makes total sense. It's true after all, turns out putting most of the work on your server rather than your client is a great idea for performance. You seem to be taking personal offense to using React Server Components for this, which is odd to me.

You do know you can move to the server without RSC? This misconception is exactly what I'm talking about.

Re: React Server Components made our site a lot faster

#46

Earlier quoted context omitted.

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

> 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' fo…

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.

Re: React Server Components made our site a lot faster

#47

Unbelievable, deceptive levels of clickbait at play - they moved from a client app to a server app, so of course the initial render is faster. This has nothing to do with RSC, and @dang /moderators should probably change the headline. "Moving from a client-side app to a server app (using React Server Components) made our site faster" is very unsurprising, not very interesting (what would be interesting is comparison…

This is a weird take, given that RSC is generally positioned for this kind of conversion. Among others, sure, but this is definitely one. It’s not deceptive to write about using a tool for one of its explicit intended purposes.

See this: https://news.ycombinator.com/item?id=37608452

Re: React Server Components made our site a lot faster

#48

Earlier quoted context omitted.

It's not that RSC is a bad thing, there's just a lot of animosity built up from years of react developers shitting on the concept of processing on servers and antagonizing the developers who work in that space. Then, hey, it turns out those idiot backend devs that were so looked down upon may actually have known what they were doing after all. There's also the bit where RSC seems wonderful if all you know is react bu…

I have yet to meet a frontend dev who called a backend dev an idiot. I have met plenty of backend devs who have indirectly called frontend devs idiots.

I agree as well, having worked on both sides (and "full stack"). Not really calling "idiot", but more of the bias that frontend development is easy and not "real" programming whereas I've never personally seen the reverse attitude.

I have only worked at more "traditional" companies so that likely influences my experience as well, it may be different at different kinds of companies.

Re: React Server Components made our site a lot faster

#49

Earlier quoted context omitted.

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

> 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' fo…

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

The article is about a mostly-static marketing page.

Re: React Server Components made our site a lot faster

#50

Earlier quoted context omitted.

This is a weird take, given that RSC is generally positioned for this kind of conversion. Among others, sure, but this is definitely one. It’s not deceptive to write about using a tool for one of its explicit intended purposes.

See this: https://news.ycombinator.com/item?id=37608452

It seems as though you’re reading this article—and apparently others on the topic—as some form of attention metric gaming combat. I think the author just, uh… wrote an article about their experience with adopting a technology.

You clearly have familiarity with the technical landscape, perhaps more than most here! And maybe I’m projecting this part, but my hunch is that (like me) you follow the space closely? If I may offer some advice, for whatever it’s worth: there’s going to be a very long tail of people coming to this, or any similar, solution with less depth of knowledge and nuance, and it might be a more enjoyable reading experience to preemptively give them some grace on that.

Post reply on HN