Why would you choose then to have two completely different ways of managing data? It’s insanity. It’s like saying “you can totally use kubernetes to deploy your app and then later switch to swarm and support both!” (And even that analogy doesn’t capture the ridiculousness of doing this, as in that case you’re mostly changing higher level glue code, whereas with RSC your actual data management code would be totally different).

Yea, technically you could, but why choose something far more complex that actually actively makes your app like experience worse?

Apps want to handle data local-first, offline-first, with optimistic mutations, cached data between screens, instant animations with interactions between screens, etc. The ideal data model for this is something like firebase, parse, graphql, tinybase, etc.

So now some bozo on your team bought into the hype and blindly wants to shove RSC into it and you’ve completely ruined the elegance of your stack. Instead of having a single codebase with a single abstraction for data fetching that’s clearly better than server-first, you now have two abstractions, and the server based one ruins all the things that make apps better than sites.

It also doesn’t make anything faster for web. You can avoid shipping some JS without RSC, the React team just decided for some reason to couple avoiding sending parts of the tree with a whole new data fetching model, a complete self-own and big mistake. It’s no wonder Vercel the server selling company loves them.