3 ms·
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 re
by metalrain 1y ago
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.
- pas 1y agoIt'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.)
- robertoandred 1y agoRSCs work just fine with static deployments and SPAs. (All Next sites are SPAs.)
- ec109685 1y agoHow 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?
- presentation 1y agoThat's fine for you, but not all React users are you. It makes much sense in practice for me.