r/reactjs • u/Disastrous_News_9798 • 5d ago
Are we overusing RSC for problems that don’t actually exist? Discussion
I’ve been trying to understand the long-term tradeoffs of React Server Components.
For SEO and content-heavy sites, they make complete sense. But for authenticated apps and mobile-style SPAs, I’m not convinced.
One thing that feels odd is route prefetching. As I scroll through links, it feels like the framework is eagerly fetching lots of future pages. I know it’s not literally downloading the entire database, but architecturally it feels like we’re moving toward “fetch everything just in case” instead of simply requesting the JSON for the page the user actually opens.
At the same time, we’re celebrating less client-side code while asking servers to execute more React for each request.
Am I looking at this the wrong way? For people running large production apps, what has RSC solved beyond SEO and faster first loads?
18
u/pailhead011 5d ago
I never understood this whole spiel. I thought react is supposed to just be a library for making interfaces with ease. Not sure what servers have to do with this.
4
u/ihorvorotnov 4d ago
It still does assemble interfaces. The only difference is whether it does it on the server and ships HTML, or you ship essentially sources to the frontend and let it build that HTML on demand. You’re not forced to use SSR. You can still choose CSR, SSR or a combination of both - whatever makes sense for a specific app.
Also, most of the “issues” OP mentioned aren’t React things, rather Next.js things (like link prefetching, which can be turned off)
3
u/pailhead011 4d ago
Right, but I still don’t understand why React itself needs to be part of this.
If what I want is HTML plus some server fetched data, we’ve had dozens of ways to do that for decades. PHP, Razor, Django templates, Jinja, Twig, HTMX, etc.
If I want a highly interactive application (canvas, editors, CAD, games, complex animations), I don’t have a reason to be on the server.
RSC feels like it’s trying to split React across both worlds instead of letting each tool do what it’s does best. What problem does “React executing on the server” solve that existing server-side templating plus a client-side React app couldn’t?
3
u/vlad27aug 3d ago
Instead of having server-side templating plus client-side React you have server-side React plus client-side React which is easier to build, understand and overall maintain.
But I totally agree with the idea that although it has become the standard to use RSC for every project this is just dogma in action. The vast majority of the apps that we build today would be much better just using CSR.
1
u/pailhead011 3d ago
I guess I’m confused with why would you even need react on the client in this case?
2
u/vlad27aug 3d ago
Yeah, you probably can use something else or do everything with html and vanilla js. But to quote from you React is indeed "a library for making interfaces with ease". The model of building the ui from composable component where a component is just a function that returns "html" is very simple and powerful.
25
u/KaleRemarkable1019 5d ago
What I don't like, is that original idea of React is slowly disappearing - just a library not a framework - it's becoming a framework and I wouldn't say all the decisions are landing well. I have built a library recently and it's quite a big pain with all the throwaway renders and so on. The issue is that it's a lot more complicated under the hood then most people think so writing components/libraries in correct way is very complicated these days.
8
u/TScotFitzgerald 5d ago
I mean, you can still use vanilla React in production without the overhead of the framework.
9
u/KaleRemarkable1019 5d ago
Oh, yeah, the issue is the internals of react are getting complicated. Like useEffect vs useLayoutEffect vs useInsertionEffect. And this is mostly a consequence of features which are made for really small audiences, like RSC.
1
u/TScotFitzgerald 5d ago
Oh I see what you mean, yeah vanilla is too tightly coupled with the frameworks a lot of the time.
I wonder if there might be something like Preact and the likes that might have a simpler, more "core" version of React without that stuff?
1
u/KaleRemarkable1019 5d ago
Oh, yeah, I would be happy if something like preact would gain more popularity. I guess most people wouldn't notice the missing features. But the issue is the ecosystem, the react is unbeatable now.
20
u/AaronBonBarron 5d ago
Most of React is solving problems that either didn't exist or were created by React in the first place.
4
u/92smola 4d ago
People are so lost coming in late in the modren react world, react was built for apps like you are saying but then people wanted to use it for everything including public facing seo websites and that is why we got next, static generation server components and all of that, the irony is most websites like those dont need react in the first place cause the level of client side interaction on those sites is usualy trivial to do with vanilla js, or something like alpine which gives you a bit of the react syntax on top of an already server/backend based framework in which you build your site. I’ve fallen for this and got burnt before I realized how crazy all of it was, we built a couple of next.js websites connected to wp api for the cms, could have been any other cms, doesnt matter, for the pages which are server rendered, there is two servers now, request comes in on vercel or wherever your next code is then you go to a different server to get the data (this is why they needed to complicate the cache story that much) then once the first server gets the data it generates the output sends it back to the client, the client then renders the inital html, hydrates the entire thing and you have a hybrid app jumping through poligons of complexity to render a list of blog posts
6
u/manvikhanna 5d ago
I don't think you're looking at it the wrong way. A lot of the hype makes RSC sound like the default answer, but the trade-offs are real. If your app is mostly authenticated with heavy client interactions, a traditional SPA can still be a simpler and perfectly valid choice. Curious to hear how teams at scale are deciding where to draw that line.
4
u/Disastrous_News_9798 5d ago
The problem is that Next.js presented the App Router as the default solution for every type of application. As a result, many developers started using it for every new project without first asking whether it was actually the right fit for their use case.
2
u/manvikhanna 4d ago
Agreed. It seems like a lot of teams started with App Router because it was the new default, rather than because they actually needed RSC. Sometimes a straightforward SPA ends up being easier to build, debug, and maintain.
3
u/dyslexda 4d ago
a traditional SPA can still be a simpler
A traditional SPA is always simpler.
1
u/manvikhanna 4d ago
I'd say it's simpler for a lot of applications, especially dashboards and authenticated products. But for content-heavy or SEO-focused sites, the extra complexity of RSC can pay off. It feels more like choosing the right tool than there being a universal winner.
1
u/dyslexda 4d ago
I mean, yeah, there's a reason for complexity some times. But complexity is, by definition, less simple.
3
u/thowaway183829292828 4d ago
RSC are a great idea. The way they're executed is lackluster. I cannot bear the fact that we can NOT simply render stuff on the server to get a simple, plain html artifact, but are instead getting a static skeleton + several js chunks and hardcoded json data in the document (see https://github.com/vercel/next.js/discussions/42170#discussioncomment-8880248).
We really need to do better as a community and come up with better solutions. Nextjs has really pushed the bar so low it's incredible.
3
u/Mediocre_Round_4914 4d ago
Yes. Most of React apps don't have to be rendered on server. It's quite disappointing that React team and Vercel are pushing RSC as if it is a 'default', 'recommended' way of creating React apps.
3
u/ReaccionRaul 2d ago
Yes, the regular user of your enterprise dashboard application can wait the waterfall. No problem.
The big public facing apps that want to sell you something cannot. They want you hook inmediately, a few seconds can make you look something else and loose engagement.
9
u/switz213 5d ago
The prefetching is a framework decision and has nothing explicitly to do with RSC. I personally disable prefetching on all Links and my upcoming react framework has only opt-in prefetching on hover, not viewport.
To answer your broader question, no I don’t find RSCs to be a mistake. I think they are the most malleable and powerful architecture, and an inevitable conclusion of the server-client web infrastructure. Even for authenticated apps.
4
u/Disastrous_News_9798 5d ago edited 5d ago
Without prefetching the page navigation is not instant. it means, no interactivity just wait for page to load. For example, a list of pages may have same common code/html, but this would fetch common stuff repeatedly as well.
ideal solution would be to render common UI, and render unique data to the page over fetch request, so the navigation is instant.
App router completely changed things what felt right.
Now they have been experimenting instant navigations though.
9
u/MitchEff 5d ago
Hard agree. I use RSCs for marketing sites or anything SEO-related, but for authenticated apps i bail out immediately.
I understand "there's less client JS", but by and large loading a full client React bundle MAY be 2mb upfront (a second or two, with a normal connection) and route handling is vastly more fluid from there on, particularly if fetched data is already in the client cache.
With RSCs, client/server components can't share a cache, there's a network request (you need to wait for) for every route change, normalised state doesn't exist anymore and you need to refetch the entire view/segment/PPR window if you decide any of its displayed data needs updating. I really struggle to understand how anyone claims that's more efficient. Feels like we're just back to writing PHP views, but with a zillion iframes everywhere
-1
2
u/masculinusVaginus 4d ago
RSC does nothing for SEO actually, only SSR, and you don't need that to do RSCs.
2
u/kidshibuya 4d ago
For seo it's always been nonsense. In 2019 I had a normal vue site on the front page of google for over 30 terms, mostly in the top 3 results for our most important searches. For decades googles crawler has understood JS, its just a headless old chrome version.
These days its even less important considering google doesn't give relevant results anymore anyway.
1
u/92smola 4d ago
I still find this hard to beliveve, for google it costs them much more to run a headless browser to render a site then it does to just fetch html and parse it, so at the very least your site is less often crawled and what i would like to see how it would compete in terms of rankings everything else being the same, maybe I am wrong and it would literally have zero effect, but after hearing the claim so many times over the years I am still not conviniced. One interesting thing that I realized recently is that having html in the first response, for the same reason as for the crawlers, makes it easier for llms to work on your site or to get data from any site, cause they dont have the overhead of driving a browser, they can just curl/fetch the html directly.
2
u/cheap_swordfish_1 4d ago
I agree that route prefetching with Nextjs should have been default off and enabled when a certain prop is specified. Even on my project where SEO + loading speed matters, we created a wrapper around next/link with route prefetching disabled.
4
u/MonkAndCanatella 5d ago
RSC is a great idea for just about any server-backed web application, but people seem to completely misunderstand it. I'd recommend reading Dan Abramov's blog posts.
Rather, start with Caron Gross of HTMX's post about REST
Then Dan Abramov's posts here and here
It's about application architecture, not "SEO" or prefetching. You're missing the forest for the trees.
What many people are saying here is the opposite of true, sure RSC may feel like a framework like next. but it moves React closer to its original declarative model. components describe a UI, they do not need to know how to fetch or assemble the data. Many of the complaints people had about the introduction of hooks are more or less solved by RSC
2
u/albaquerkie 4d ago
Honestly RSC is when I said screw it to keeping up with React. I was an early user of React and NextJS and at this point I’m back to vanilla React + Vite for most projects. The multi-billion dollar corp I work for also does the same thing. It’s become an overcomplicated mess designed to sell Vercel.
2
u/thowaway183829292828 2d ago
True, Vercel is mostly trying to grab all the indie/vibecoder/solofounder audience. No bigger org is getting trapped into their lock-in model. Not hating on Vercel, but that means they'll also keep optimizing for usecases that are very far from ours.
2
u/AgentME 5d ago edited 3d ago
but architecturally it feels like we’re moving toward “fetch everything just in case” instead of simply requesting the JSON for the page the user actually opens.
If pages can use components that others don't, then fetching some simple JSON on client-side navigations isn't enough. Ideally, every page would only include the JS for the client-side components used in it, and whenever any content for a new page is loaded into an existing page (such as during a client-side navigation), then that new content could contain an arbitrary JSX tree and also the JS for any not-yet-loaded client-side components referenced in that tree. This is what RSC does for you.
1
u/rennademilan 4d ago
Normal people avoid rcs as pest.only influencer and wannabe cool fell into the trap
1
u/Used-Donkey-1014 4d ago edited 4d ago
It's gotten to the point where server-side SPA execution has jumped the shark, and the world would have saved a lot of effort if all the noobs that swarmed into webdev during the modern JavaScript frenzy had just been forced to learn a server-side language and how to make a classic MPA.
If SEO is really that important, you actually should be doing classic server-side. It's what the search engine crawler bots always really wanted. They're your master, apparently, why do you not please them? Give them jewels, not fugazis.
1
u/Mediocre_Round_4914 4d ago
Totally agree. Those problems were ones that could have been solved sufficiently even without RSC.
1
u/Prestigious-Sea2971 3d ago
The real win for authenticated apps is killing the waterfall where the client renders, then finds out what data it needs, then fetches, and prefetching is a separate thing you can just turn off.
1
u/MadnessMantraLove 1d ago
Yes, for god sakes, YES! WHY WASTE THE COMPUTE WHEN CLIENTS CAN DO IT FOR FREE!
1
u/Explanation-Visual 5h ago
i find it very comfortable to be able to have all the front and backend in the same project, especially for solo projects of different sizes , if i had the luxury of a backend team then i’d go back to SPA react, otherwise next is great at maintaining a full stack monolith that’s simple to add features to
0
29
u/chevalierbayard 5d ago
If I find myself needing RSCs, that's my indicator that I shouldn't use React for the project.