Denial of service and source code exposure in React Server Components

Post by JeremyNT » Fri, Dec 12, 2025, 4:09 AM UTC

_jzlw wrote: post #81

chuckadams wrote: post #2

I remember when the point of an SPA was to not have all these elaborate conversations with the server. Just "here's the whole app, now only ask me for raw data."

It's funny (in a "wtf" sort of way) how in C# right now, the new hotness Microsoft is pushing is Blazor Server, which is basically old-school .aspx Web Forms but with websockets instead of full page reloads. Every action, every button click, basically every input is sent to the server, and the changed dom is sent back to the client. And we're all just supposed to act like this isn't absolutely insane.

Post by kyleee » Fri, Dec 12, 2025, 4:20 AM UTC

c-hendricks wrote: post #96

berekuk wrote: post #90

Earlier quoted context omitted.

I've been using React since its initial release; I think both RSC and App Router are great, and things are better than ever. It's the first stack that allows me to avoid REST or GraphQL endpoints by default, which was the main source of frontend overhead before RSC. Previously I had to make choices on how to organize API, which GraphQL client to choose (and none of them are perfect), how to optimize routes and waterf…

Some of the anti-next might be from things like solid-start and tanstack-start existing, which can do similar things but without the whole "you've used state without marking as a client component thus I will stop everything" factor of nextjs. Not to mention the whole middleware and being able to access the incoming request wherever you like.

Post by bryanrasmussen » Fri, Dec 12, 2025, 4:42 AM UTC

Uehreka wrote: post #55

tom1337 wrote: post #26

Earlier quoted context omitted.

I was a fan of NextJS in the pages router era. You knew exactly where the line was between server and client code and it was pretty easy to keep track of that. Then I've began a new project and wanted to try out app router and I hated it. So many (to me common things) where just not possible because the code can run in the client and on the server so Headers might not always be available and it was just pure confusio…

I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…

Post by 0xblinq » Fri, Dec 12, 2025, 4:54 AM UTC

simonw wrote: post #16

React Server Components always felt uncomfortable to me because they make it hard to look at a piece of JavaScript code and derive which parts of it are going to run on the client and which parts will run on the server. It turns out this introduces another problem too: in order to get that to work you need to implement some kind of DEEP serialization RPC mechanism - which is kind of opaque to the developer and, as we…

Post by robertoandred » Fri, Dec 12, 2025, 4:56 AM UTC

stack_framer wrote: post #121

Uehreka wrote: post #55

Earlier quoted context omitted.

I think we (the Next.js user community) need to organize and either convince Vercel to announce official support of the Pages router forever (or at least indefinitely, and stop posturing it as a deprecated-ish thing), or else fork Next.js and maintain the stable version of it that so many of us enjoyed. Every time Next comes up I see a ton of comments like this, everyone I talk to says this, and I almost never hear a…

I find myself just wanting to go all the way back to SPAs—no more server-side rendering at all. The arguments about performance, time to first paint, and whatever else we're supposed to care about just don't seem to matter on any projects I've worked on. Vercel has become a merchant of complexity, as DHH likes to say.