zlacker

[return to "RCE Vulnerability in React and Next.js"]
1. halfli+yO[view] [source] 2025-12-03 19:52:44
>>rayhaa+(OP)
Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve?

What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering?

Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compiler, but instead of going the svelte route of handling the entire state, it only adds memoization?

If I can send a direct message to the react team it would be to abandon all their current plans, and work on allowing users to write native JS control flows in their component logic.

sorry for the rant.

◧◩
2. danabr+XQ[view] [source] 2025-12-03 20:03:42
>>halfli+yO
Server Components is not really related to SSR.

I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a <script> (server calling client). You can still have an API layer of course, but this gives you a syntactical way to express that there's a piece of backend that prepares data for this piece of frontend.

This resolves tensions between evolving both sides: the each piece of backend always prepares the exact data the corresponding piece of frontend needs because they're literally bound by a function call (or rather JSX). This also lets you load data as granularly as you want without blocking (very nice when you have a low-latency data layer).

Of course you can still have a traditional REST API if you want. But you can also have UI-specific server computation in the middle. There's inherent tension between the data needed to display the UI (a view model) and the way the data is stored (database model); RSC gives you a place to put UI-specific logic that should execute on the backend but keeps composability benefits of components.

◧◩◪
3. halfli+yV[view] [source] 2025-12-03 20:23:26
>>danabr+XQ
Thanks for the comment Dan, I always appreciate you commenting and explaining in civility, and I’m sorry if I came a bit harsh.

I understand the logic, but there are several issues I can think of.

1 - as I said, SSR and API layers are good enough, so investing heavily in RSC when the hooks development experience is still so lacking seems weird to me. React always hailed itself as the “just JS framework”, but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.

2 - as react was always celebrated as an unopinionated framework, RSC creates a deep coupling between 2 layers which were classically very far apart.

Here are a list of things that would rather have react provide:

- advanced form functionality that binds to model, and supports validation

- i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed

- signals, for proper reactive state

- better templating ability for control flows

- native animation library

All of these things are important so I wouldn’t have to learn each new project’s permutation of the libraries de jour.

◧◩◪◨
4. mexico+qU2[view] [source] 2025-12-04 13:04:44
>>halfli+yV
> React always hailed itself as the “just JS framework”,

I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming.

> but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing code.

This is wild. Yes you can. You can write regular JS in components. I can go build a component right now that uses JS (either with or without hooks). You're conflating the rules of hooks with the ability to use Javascript. Yes, there are rules. No, that doesn't mean you can no longer can write JS.

> i18n, angular has the translations compiled into the application and fetching a massive json with translations is not needed

Tradeoffs. Now each update needs to be rebuilt and redeployed. I don't have that problem in React.

> better templating ability for control flows

Better templating? React uses JSX. Are you saying there exists a better way to control flows than if/else?

> signals, for proper reactive state

This has been debated ad-nauseum in the React community and everything has a trade-off. I wish people would stop saying this as if it's categorically correct. React is UI is a function of state. Singlars would totally break the current mental model of React. Data flows down. This change would come with tradeoffs.

[go to top]