Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While RSC as technology is interesting, I don't think it makes much sense in practice.

I don't want to have a fleet of Node/Bun backend servers that have to render complex components. I'd rather have static pages and/or React SPA with Go API server.

You get similar result with much smaller resources.



It's convenient for integrating with backends. You can use async/await on the server, no need for hooks (callbacks) for data loading.

It allows for dynamism (user only sees the menus that they have permissions for), you can already show those parts that are already loaded while other parts are still loading.

(And while I prefer the elegance and clean separation of concerns that come with a good REST API, it's definitely more work to maintain both the frontend and the backend for it. Especially in caes where the backend-for-frontend integrates with more backends.)

So it's the new PHP (with ob_flush), good for dashboards and big complex high-traffic webshop-like sites, where you want to spare no effort to be able to present the best options to the dear customer as soon as possible. (And also it should be crawlable, and it should work on even the lowest powered devices.)


How do you avoid having your users stare at spinners while their browser makes api calls (some of them depending on each other) in order to render the page?


That's fine for you, but not all React users are you. It makes much sense in practice for me.


RSCs work just fine with static deployments and SPAs. (All Next sites are SPAs.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: