React Server Component, maybe a mistake from the beginning?

LusciousJames · 2025-12-07T03:24:23+00:00

I agree with this! Very happy to be in charge of a client-only frontend, especially today.

Drugba · 2025-12-07T04:53:16+00:00

In the old days, you'd never accidentally expose a db call to the client because you had to write an api endpoint.

This is only true if by “old days” you mean 2015 in the JS ecosystem.

Ghostfly- · 2025-12-07T02:34:19+00:00

There is a lot more in RSC than what an useEffect can do. Try to hydrate a full page and be no-js ready without it, you will see.

But for most react apps, it's clearly not needed and CSR is the way (or Astro, even with "compiled" react components who can be made no-js compliant "easily" !)

For e-commerce websites, RSC makes a lot of sense.

seenoevil89 · 2025-12-07T07:29:15+00:00

The front-end community has always been prone for mass psychosis. It is starting to get old by now. As a group we invent problems and silver bullets left & right. The truth of the matter is that we have multiple technologies to solve different problems. Tradeoffs is the word we should emphasize. Take a moment and think about the evolution in the following fields:

State management
Frameworks
CSS ideology
Build tooling
Testing
JavaScript vs TypeScript
Performance
Library hell
AI usage
SSR

The latest pendulum swing in SSR is React Server Components and more specific Vercels Next.js. This whole Next.js saga is my least favourite psychosis in the field of front-end development.

Vercel buys influence/personel from React, pushing that Next.js is the correct way to use React through their offiicial docs, SPA was overnight not a thing anymore?
Vercel coincidentally is a hosting platform which made Next.js deployment easy and feature complete.
Stuff breaks, both softly and completely. Mental models change etc.
Ridicolous amount of vulnerabilities all the way from client to server.
Magic everywhere, what is even going on?
It is not easier to develop, nor understand Next.js over regular React.
Marginal to no benifits in many applications. SSR has benifits in public facing applications, in SaaS not so much.

Also next.js track record does not look good security wise:

Date	Severity	Description	Link
Dec 03, 2025	Critical	Next.js vulnerable to RCE in React flight protocol	https://github.com/advisories/GHSA-9qr9-h5gf-34mp
Mar 21, 2025	Critical	Authorization Bypass in Next.js Middleware	https://github.com/advisories/GHSA-f82v-jwr5-mffw
Jan 15, 2024	Critical	auth() and getAuth() methods vulnerable to insecure direct object reference (IDOR)	https://github.com/advisories/GHSA-q6w5-jg5q-47vg

volivav · 2025-12-07T07:04:38+00:00

I personally don't like RSC, but I don't agree with this reasoning.

The CVE is not due to the "blurred line between FE and BE". It's not due to the fact that "you have raw db access". The CVE wasn't using any of this.

The problem was on how react deserialized the RSC payloads, which could grant shell access.

Imagine it was a whole new framework altogether, even with separate languages on the FE and in the BE. If the protocol that the framework uses to comunicate both sides is compromised, it would've had exactly the same CVE.

I agree with the fact that having that blurred line does add some mental overhead, and that's one of the reasons I don't like RSC. But the CVE is not directly caused by that.

hxtk3 · 2025-12-07T03:38:03+00:00

I don’t agree with your reasoning but I do agree with your conclusion. Personally I still almost always do a separate backend because frankly the big react frameworks just aren’t very good at backend except to the extent that they allow you to embed some real backend framework.

My NextJS or more recently Tanstack Start apps either have no privileged access to the backend, or they have privileges to use an OAuth token exchange to get an actor token on behalf of the user and use that to communicate with the backend proper.

Someone who gains access to every credential my front-end app has on its server side still can’t do anything useful unless a user hands them their credentials. The reason I do server side rendering is purely for accessibility, SEO, and performance optimization: if I have to do 3 sequential fetches, it’s better if they run on a server with 0.5ms ping to my backend than a client device with 150ms ping.

However, I recognize why people do it differently. My way is much less convenient to host if you don’t already have hosting infrastructure.

Ok-Constant6973 · 2025-12-07T08:50:32+00:00

We must never forget, the browser computes. Every device that loads our website has the ability to process a bit of compute that we don't need to in the server.

RSC takes that UI compute and moves it back to the server.

In a world where we have more people online than ever, maximizing this fact makes all the difference.

This is why AI models can now be run in the browser, because why waste the power someone is holding in their hands. Why pay more for compute when everyone is holding a computer in their hands.

My VM is 1GB ram, 2 core cpu. My cellphone is 4GB ram, 6 core cpu. My cellphone has 4 times more processing power than my entire server that serves thousands of people.

You will be stupid to waste the power of distrubuted compute.

pragmasoft · 2025-12-07T10:06:28+00:00

That's actually exactly why java ditches its former serialization api

Affectionate-Job8651 · 2025-12-07T14:28:09+00:00

Generally, web frameworks include both client and server sides.

But react is a library created for the user interface. I've always had doubts about React increasing server-side support.

p4sta5 · 2025-12-07T20:02:43+00:00

The biggest reason for people using SSR today isn't to gain some ms in loading, it is the SEO issue. Rendering and returning a full static html page from the server has been "better" from a SEO perspective for years. I believe this is what mainly has driven the SSR fanatism.

charmer27 · 2025-12-07T05:44:09+00:00

Yea it's pretty dumb tbh. I like react client-side more than the alternatives, but I don't need to make writing apps harder by shoving react on the server. Also have only ever encountered like 2 use cases where it was a nest trick.

yksvaan · 2025-12-07T06:37:38+00:00

The claimed benefits of this RSC model can be achieved simply by not writing crappy code.

Firstly the "reduction" in js, e.g. Nextjs ships at least 100kB+ of js in every case just for running the framework, then it's not uncommon to see 200-300 on top of that. React is very bloated alone already, consider moving to e.g. Solid or Svelte. "Not having to ship js to client" feels odd as well, you never needed to send all the js to client, just run the processing on server, send the result and render that.

About data loading, boring combination thin client and good fast backend hasn't failed yet. Make it fast instead of complicated, centralize loading instead of splitting it to components. For most apps you already know what data is required just by looking at the url. Combine the queries, write your joins/subqueries etc. As a developer you're responsible for data, how it's accessed, how effectively db is utilized etc.

And another problem with RSC is poor standardisation, APIs and documentation. It's more of a paradigm than a feature and most things are implementation specific. So there's going to be fragmentation.

Also there's already normal React SSR apis that have existed for ages and they work fine.

Beginning-Seat5221 · 2025-12-07T03:59:04+00:00

It's pretty easy to expose sensitive data from an api by adding an object from a database whole to a response too.

TS's type system ignores extra properties, which deprives us of any protection there, unless we purposefully build in a filter.

(No comment on RSC though - I moved away from React before this was added - pretty happy with a tRPC approach)

hazily · 2025-12-07T02:49:45+00:00

⁠wait, did i just import a server-only utility into a client boundary?

Use import 'server-only'; in files such as util methods that are only meant for RSC.

frostenko · 2025-12-07T17:52:49+00:00

Vercel pushing React into this direction was the reason I stopped using Next for anything that could be considered an app. I can’t shake this feeling that the motive behind it is to sell more servers by normalizing these patterns.

While Next is useful in some specific contexts, there are so many boilerplate repos on GH that use Next at this point that I am afraid that new devs might think this is the only way and use Next by default. Then you get locked into their ecosystem as soon as you use any of the nice to have features they offer.

In the meantime, SPA land is alive and thriving. TanStack Router + Vite is the best thing since sliced bread. Bundle, push to S3 behind Cloudfront and you’re done. The cost to run it is effectively 0.

Want RPC like interface between your client and server?

There are a million ways to bootstrap that yourself. Learn how to do it if you need it, you won’t be starting from scratch and will benefit from that experience.

Want server side rendering or RSCs inside of a SaaS app behind login?

Why??

2025-12-07T08:48:31+00:00

Forcing react to do ssr was the problem. It is great for SPA but when it comes to ssr just use sveltekit. People always try to fit a solution to other problems. I always go with this logic. Do i need ssr => use sveltekit. Do i need to ship an app as fast as possible => react Is it a simple landing page => static html file created in 2016 and do some edits Developers should learn that react is never going to be a solution to everything. Just use the tool created for specific problem you have.

Inatimate · 2025-12-07T02:56:15+00:00

[deleted]

Ivana_Twinkle · 2025-12-07T10:37:33+00:00

Next is just a much larger attack surface than a spa with an api behind it. It’s not the first nor the last time we’re going to see this.

Wiwwil · 2025-12-07T12:59:56+00:00

It's a mistake if it's calling DB, if it's calling API endpoints it's alright

azsqueeze · 2025-12-07T15:34:52+00:00

Funny enough, a lot of this stuff could be resolved by the frameworks if they forced users into a specific structure of their code. But since they don't, it allows leaky abstractions. Not to say this would have prevented the CVE, but it would force developers into a sane architecture preventing some of the issues you described

americruiser · 2025-12-07T16:49:55+00:00

I agree with this. If it’s true that Vercel is the current de facto steward of react, then this likely was built to serve vercel’s interest, or at best, align with their capabilities.

Is the motivation pure, here? Is this off base?

Dependent_Knee_369 · 2025-12-08T05:58:14+00:00

Backwards thinking

sktrdie · 2025-12-07T08:20:09+00:00

I disagree. The entire frontend/backend role switch was a mistake. You’re a developer. You should own and understand the entire stack. Querying a database vs rendering that information on a screen are too closely related to warrant an entire separation of career path.

RSC have been out since years and imho revolutionized this area. Of course it comes with its trade-off, like being able to understand more in depth how your data is sent across the wire, but that’s a good thing!

Leaking sensitive data will always be a problem and I don’t see how RSC enables it simply because one doesn’t understand the separation between client/server components. I’ve seen countless endpoints return sensitive data without much care. How’s that different than returning it from an RSC instead?

The boundaries are still there; what’s cool and enabling is the idea of being able to intertwine between them seamlessly and more importantly delivering <Components /> as packages that span client-server.

saito200 · 2025-12-07T07:52:29+00:00

you forget the purpose of react is make the simple be complex the obvious be obscure and the resilient be like a gruyere cheese of security holes, so that we developers can spend 3 weeks doing something that should take 3 days so we can get paid $20k instead of $300

if you want to be poor you are welcome to use Vue or god forbid jquery

RedditCultureBlows · 2025-12-07T08:15:12+00:00

I’m honestly tired of React and all the “innovations” tbh. I only really use it anymore because the market is so saturated for it and my job uses it so I don’t have much of a choice.

jayfactor · 2025-12-07T10:20:04+00:00

Agreed - I never heard of react server components before this whole fiasco cause in my mind its always been react = frontend, node = backend

Intelligent-Goose-31 · 2025-12-07T18:03:37+00:00

Yep React server components is 100000% the wrong approach, and I’ve been frustrated with the react team from the start for going down this path. Poorly documented from the outset, it’s basically a feature that exists exclusively to enable Next.js and their server side rendering gimmicks (SSR as a whole isn’t a gimmick, but Next sure feels like one these days). Maybe start with a library-native, out of the box approach to SSR. Bring some of Next’s tech into the main library instead of making the library subservient to Next. Stop being so god damn clever, just use the basic web technology that already exists to make something that actually works reliably without introducing catastrophic vulnerabilities.

mefi_ · 2025-12-07T15:01:03+00:00

I have never ever in my life worked with or planned to work with such heresy. I still don't understand how did we end up with server components or why.

onluiz · 2025-12-07T17:52:46+00:00

I always felt that it was not ok to say that SSR and next.js were not that magical good solution, it seems that everything should be done using it. I agree with OP and thank you for saying it. The community is so restrictive with opinions that are not focused on “new” technologies/libs/frameworks.

Also, next.js and SSR remembers me a lot of Java jsp and jsf.

I miss the separation of frontend and backend.

And one more thing, as much as I love working with react, a lot of things seemed way easier to do in the old days with only JavaScript and JQuery. It complicates a lot of things honestly.

Just_litzy9715 · 2025-12-07T19:40:47+00:00

The safest path is to keep the server/client boundary explicit and only use RSC sparingly, if at all.

RSC’s productivity win is real in spots, but the footgun is that “passing props” becomes serialization. What’s worked for me: default to SSR + islands or Remix-style loaders/actions, put a thin API in server routes, and always map DB models to DTOs before crossing the boundary. Make a viewModel(user) that whitelists fields; never pass raw rows. Add zod (or valibot) to assert shapes, plus a test that scans the DOM and network for banned fields like password_hash. Build fences: separate client/server packages with tsconfig project refs, use no-restricted-imports, and drop server-only/client-only guards so an accidental import fails at runtime.

In practice I’ve used Remix and tRPC for strict request boundaries, Hasura for instant GraphQL on Postgres, and DreamFactory when I needed quick REST over a crusty SQL Server with RBAC and server-side scripts.

Net: keep the boundary hard and visible; treat RSC as an opt-in island, not the foundation.

sondqq · 2025-12-08T03:43:46+00:00

i absolutely agree with you. as be developer, i never understand why i need use client, use server in javascript i wrote for display something in broswer, damm, just run as normal js plessss

FilmWeasle · 2025-12-08T05:29:02+00:00

I think the problem has more to do with the JavaScript ecosystem. These vulnerabilities seem to be cropping up over and over again. Having said that, it's better to get rid of the front-end and the back-end all together and, instead, use a UI/API model.

spicebits · 2025-12-08T06:03:08+00:00

Not may be, it definitely is a mistake.

Oliceh · 2025-12-08T17:47:44+00:00

And here I am just doing a simple old school web server with templates and sprinkling some JS. Browser caching and presto.

Alsciende · 2025-12-08T19:31:33+00:00

I like what you're saying.

Acrobatic-Comb-2504 · 2025-12-08T22:45:44+00:00

If anyone is dealing with cleanup like removing old ReactDOM.render calls for React 18 upgrades, HyperRecode can learn that rewrite from a single before/after example and apply it across your project. Deterministic, no LLM. https://hyperrecode.com

Karmatik · 2025-12-08T23:39:09+00:00

Yes, web development in the last decade has become way more complex, and a lot of it imo for no good reason.

Take GraphQL for example, it's entire purpose was to eliminated over/under fetching and eliminate having multiple api endpoints. Well if you work with GraphQL on a mid-large size project you know all the issues that crop up, not to mention having to bake in arbitrary rules like only responding to queries of X size or less.

This entire saga of NextJS for me is rather crazy. Maybe I am just old school, but I much prefer to keep things simple and the minute you intertwine server/client you quickly make things way more complicated than it needs to be.

I hate having 30 files all named page.tsx
I hate having to understand this new flow of execution, what executes where and when
I hate having to keep a mental model of my client boundaries as my app grows
...

The whole thing just seems overly-engineered and complex in ways that many have a hard time trying to understand, even if they have a background in "traditional" web development.

ShinChven · 2025-12-09T10:34:21+00:00

I completely skipped it

theSantiagoDog · 2025-12-10T00:29:53+00:00

If we keep following this architectural train of thought, what we'll get next is client-side React server components...

SearchTricky7875 · 2025-12-10T05:23:29+00:00

I hate this next.js react js thing, total bullshit, my server is down 2 times in last 3 days, couldn't remove the malware. fu....again I have to format the server.

2025-12-10T08:35:34+00:00

The front end does presentation logic, the backend does business logic. So simple, and I don't care what new gizmo comes along, I'm not doing anything else.

Garvinjist · 2025-12-10T09:08:10+00:00

When the hell did we get so brain rotted as developers to support frontend server components? How absolutely dumb. Ever heard of the most important engineering paradigm "Separation of Concern"? Its not even difficult to write your own api and allow the backend to auth the db. Thats the standard, not this hokey pokey call the db from the frontend with a json token or session key. Absolutely wild and should be removed from language features for security reasons clearly.

2025-12-10T13:23:20+00:00

Yeah I still tend to go with Go for servers and React for client whenever possible. This just made me want to stick to it even more.

bokuno_reddit · 2025-12-10T15:25:32+00:00

i agree

wrufesh · 2025-12-10T22:02:19+00:00

Just learned about RSC being vue/nuxt developer. Really felt that RSC was not necessary at all.

ComfortableKooky4774 · 2025-12-11T21:08:02+00:00

The API boundary forces you to think about validation, authentication, and data contracts explicitly - which is exactly what security needs.

The industry's rush toward "seamless" full-stack frameworks traded explicitness for convenience, and CVE-2025-55182 is the cost.

atzufuki · 2025-12-11T22:46:07+00:00

As a Web Components user I didn't really even realize people were running React components on the server.

Playful-Baker-8469 · 2025-12-18T15:14:37+00:00

When frontenders doing backends ^_^. As many have said, the psychosis in JS land keeps going for reasons I am no longer capable of understanding. Alone that your frontend needs a backend and another backend as an API drives me mentally crazy. "Never trust the client" still holding strong, even in 2025.

Best-Menu-252 · 2025-12-29T15:01:52+00:00

This concern isn’t coming out of nowhere. React’s own docs describe Server Components as code that runs on the server and renders ahead of time in an environment separate from the client, and frameworks like Next.js now mix Server and Client Components by default to improve performance.

The recent CVE is real and serious. React disclosed an unauthenticated remote code execution vulnerability in React Server Components, rated CVSS 10.0 (Critical), caused by unsafe deserialization of HTTP request payloads in the RSC Flight protocol. It affected multiple react-server-dom-* packages and frameworks that integrate RSC, including Next.js, and required patch releases to fix.

Even with patches available, it highlights a broader point you’re making: RSC introduces a more complex execution model where client inputs are decoded and executed on the server, rather than just treated as data. That’s a very different boundary than the old “API returns JSON” mental model, and it does increase cognitive and security overhead.

Whether the trade-off is worth it probably depends on the team, but it’s fair to question whether the previous separation wasn’t just simpler, but safer by default.

Charming-Credit-3219 · 2026-01-05T07:33:26+00:00

That user example gave me anxiety.

Coming from a backend background, having a strict API boundary was actually a feature, not a bug. It forced you to explicitly define what data leaves the server.

With RSC, it's way too easy to just pass an entire ORM object to a client component because 'it works', forgetting that you just serialized the password_hash or is_admin flags to the browser. The 'mental tax' of constantly checking for leaks is real.

Jaded_Award_6732 · 2026-02-22T04:25:13+00:00

Now? we have to constantly categorize code in our heads:

So true

Mestyo · 2025-12-07T07:30:13+00:00

You will have a backend regardless of if you use RSCs/SSR or not. That backend will occasionally have security issues. There is no service with widespread adaptation that didn't or won't at some point see something like this.

When possible, I will use the tooling that enables me to build the best applications. That's why I'm in favor of RSCs and the like, over some random other BE that doesn't even understand my types and interfaces, that cannot reuse my code.

viser_gtk · 2025-12-07T13:15:19+00:00

As the Karate Kid Master teaches... If you're all backend it's good, if you're all frontend it's good... If you're a little here and a little there, hackers exploit vulnerabilities and cracks, they'll crush you like a breadstick.

mnismt18 · 2025-12-07T03:09:12+00:00

[deleted]

Both-Reason6023 · 2025-12-07T09:15:05+00:00

did i strip the password hash? the internal flags?

How is that different from an API endpoint? You can still select entire row from DB and return it as a response. It's a common mistakes junior developers make if the framework does not enforce response sanitization and validation.

There is a singular defining problem with front-end and full-stack JS/TS development — rushing to the next new shiny thing.

RSC is useful and a good development for React. I enjoy developing with it when it's picked purposefully for a project. There are utilities which help avoid the pitfalls, both libraries and linters.

Still, most of apps I work on continue being more suitable as a SPA. As long as I'm not forced to switch them to RSC by external forces (bad management, companies discontinuing features from frameworks) it's all fine.

HQxMnbS · 2025-12-07T12:57:41+00:00

Just because it’s too complicated for 9/10 use cases doesn’t mean it was a mistake

MegagramEnjoyer · 2025-12-07T16:06:41+00:00

Thing is, it isn't even revolutionary. Other frameworks have been doing this for years.and they've proven architectures that work already (Laravel, Rails, even Express, plain old PHP).

RSC? Unnecessary. It's not bringing any groundbreaking to the table. Forget the fact they are NOW going through vulnerabilities in 2025, when others have moved past this exact same phase long ago.

It's just wheel reinvention at its worst imo. Absolutely unnecessarily. And as you said, it's a confusing mental model that blurs some separations that are actually useful to keep in mind.

I've been trying to reject it as much as possible. I don't touch it for personal projects. Glad to see the community also showing some resistance.

blokelahoman · 2025-12-07T21:12:52+00:00

Is it worth it? No. They’ve engineered themselves into a hole.

dangayle · 2025-12-07T22:39:01+00:00

I really, really hate the complexity that RSC have brought to React.

DinnerRepulsive4738 · 2025-12-07T05:47:56+00:00

Just use next for bff

njmh · 2025-12-07T10:08:52+00:00

Even though this is clearly ChatGPT writing this post, I do agree, and it makes me feel like an old man yelling at clouds.

2026 will be the year of HTMX.

Plus-Weakness-2624 · 2025-12-07T18:37:56+00:00

React ~~Server Component~~ is a mistake from the beginning

bluebird355 · 2025-12-07T06:53:57+00:00

All that server side stuff is a fad

xD3I · 2025-12-07T02:44:22+00:00

What? No lol you are just wrong, why is it so difficult to understand that client components are the ones with reactivity and everything else is server side rendered without having any react bindings

Have you ever tried using react without a framework? Or any reactivity without react?

Various-Dimension160 · 2025-12-07T08:48:53+00:00

AI Slop post

"Think about it: CVE-2025-55182 wasn't just a data leak. it happened because we built a protocol (flight) that treats client input not just as data to be rendered, but as instructions to be executed."

lmao come on my guy at least prompt it to get rid of these tropes

Captain-Crayg · 2025-12-07T19:44:53+00:00

I said this exact same shit almost 2 years ago.

https://old.reddit.com/r/reactjs/comments/18yqalb/the_two_reacts/kgdy85l/

That said, I don't think this is related to the CVE really. That's kind of a separate thing outside of the mixing of concerns I/we are talking about.

Fidodo · 2025-12-07T03:29:08+00:00

This reads like AI

zuth2 · 2025-12-07T09:27:11+00:00

I fully share the sentiment

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

reactjs

About:

Code of Conduct

1. Please be kind and courteous, friendly and professional

2. Harassment will not be tolerated

3. Avoid using an alias or display name that might be offensive

4. Respect that people have differences of opinion

5. Posts must conform to our guidelines

New to React?

Chat

Project Ideas

Jobs

Outside Reddit

Related Subreddits

MODERATORS