Hey HN! I wanted to share an experiment I ran that tests the performance of RSC vs traditional client-side React on one of our product websites (productonboarding.com). I know RSC is a bit of a controversial topic since server-side rendering used to be an ancient paradigm with the shift to modern JS frameworks. As such, I went into the experiment with a healthy dose of skepticism.<p>To test this out, I conducted an experiment where I built an RSC version and a traditional client-side React version of the same website and measured performance. We were able to improve our bundle size and speed by 62% and 63%, respectively. You can find the whole writeup here. <a href="https://frigade.com/blog/bundle-size-reduction-with-rsc-and-frigade">https://frigade.com/blog/bundle-size-reduction-with-rsc-and-...</a><p>I actually enjoyed building with RSC more than I expected to, and it made for a better user experience since it rendered almost 3x faster than the client version.<p>Would love to hear any feedback and thoughts on our experiment. Have you started to use React Server Components yet, or no? Have you seen similar results?
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%".<p>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 the server _is_ the correct place for the majority of the processing to happen in most cases. The great thing with React Server Components is you don't have to change much about how you write react code, you can just define which specific components you need to render on the client side and boom, huge performance jump. Why is that a bad thing?
React Server Components drive me kind of crazy.<p>"We made a UI framework that slows down web sites unnecessarily... but don't worry! We've now made a massive addition to the framework to mitigate the problem of our own creation! Isn't it wonderful?"<p>Feels somehow akin to standing in a hole and being given a shovel to dig your way out.
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?<p>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?
Our site is dealing with a dynamic where our Core Web Vitals are already green, and thus our priority-setting folks don't see it as a priority to improve the score any further.<p>I want to be able to tell them "Hey, Green at 600ms will still give us an SEO boost over Green at 800ms, so we should do this," but I am having a hard time establishing whether that is actually true. Does anyone know for sure?
This space is evolving so fast, and I love it!<p>I feel like I am in the right place at the right time to be just so happening to be working on a better and more modern Wordpress :)<p>If client-side/server-side rendering with static and incremental loading, combined with dynamic markdown loading is your type of thing; please checkout my project and give me a star to follow.<p><a href="https://github.com/elegantframework/elegant-cli">https://github.com/elegantframework/elegant-cli</a>
I wonder how much overhead does the rendering or react on server add ?<p>If I have an API sever and then instead of calling those apis from client, I make all db calls on the server and then render the html.
How much of processing that was done was spent on rendering html.<p>Also I wonder how react server components and serverside rendering go with localfirst software?<p>I love localfirst web apps, they seem kinda incompatible with serverside apps
I must be getting older, because "everything old is new again" keeps coming to mind.<p>Only advice would be: don't follow these fads unless you a) are doing it to learn or b) can quantify tangible business value in the change. The worst reason to do it is because everyone else seems to be doing it*<p>*Unless literally everyone is doing it and the "old" thing becomes unsupported.
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.<p>This has nothing to do with RSC, and @dang /moderators should probably change the headline.<p>"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 from another server rendering technique), and wouldn't have made the HN homepage likely, but they've already cheesed their way here.