Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Denial of service and source code exposure in React Server Components

react.dev

Post reply on HN
Print view View original

71–80 of 232 posts

Re: Denial of service and source code exposure in React Server Components

#71

Post by nawgz »

reactordev wrote: post #7
tshaddox wrote: post #3

Earlier quoted context omitted.

That was indeed one of the main points of SPAs, but React Server Components are generally not used for pure SPAs.

Correct, their main purpose is ecosystem lock-in. Because why return json when you can return html. Why even build a SPA when the old school model of server-side includes and PHP worked just fine? TS with koa and htmx if you must but server-side react components are kind of a waste of time. Give me one example where server side react components are the answer over a fetch and json or just fetching an html page?

The only example that has any traction in my view are web-shops, which claim that time-to-render and time-to-interactivity are critical for customer retention.

Surely there are not so many people building e-commerce sites that server components should have ever become so popular.

Re: Denial of service and source code exposure in React Server Components

#72

Post by tacker2000 »

sangeeth96 wrote: post #41
pjmlp wrote: post #12

Earlier quoted context omitted.

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

> Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

How does Next accomplish more than a PHP/Ruby/whatever backend with a React frontend?

If anything the latter is much easier to maintain and to develop for.

Re: Denial of service and source code exposure in React Server Components

#73

Post by hollowturtle »

ivanjermakov wrote: post #56
hollowturtle wrote: post #50

Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated

git checkout v15.0.0 There we go.

Can I have v15 with the rendering optimizations of further versions?

Re: Denial of service and source code exposure in React Server Components

#74

Post by acdha »

sangeeth96 wrote: post #41
pjmlp wrote: post #12

Earlier quoted context omitted.

Until they discovered why so many of us have kept with server side rendering, and only as much JS as needed. Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks.

> Then they rediscovered PHP, Rails, Java EE/Spring, ASP.NET, and reboted SPAs into fullstack frameworks. I can understand the dislike for Next but this is such a poor comparison. If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

> If any of those frameworks at any point did half the things React + Next-like frameworks accomplished and the apps/experiences we got since then, we wouldn't be having this discussion.

This is interesting because every Next/React project I see has a slower velocity than the median Rails/Django product 15 years ago. They’re just as busy, but pushing so much complexity around means any productivity savings is cancelled out by maintenance and how much harder state management and security are. Theoretically performance is the justification for this but the multi-second page load times are unconvincing.

From my perspective, it really supports the criticism about culture in our field: none of this is magic, we can measure things like page-weight, response times, or time to complete common tasks (either for developers or our users), but so much of it is driven by what’s in vogue now rather than data.

Re: Denial of service and source code exposure in React Server Components

#75

Post by ashishb »

leptons wrote: post #63
ashishb wrote: post #34

The JavaScript fanatics will downvote me for saying this, but I'll say this, "using a single JavaScript codebase on your client-side and server-side is like cooking food in your toilet, sooner or later, contamination is guaranteed" [1] 1 - https://ashishb.net/tech/javascript/

This isn't a Javascript problem, this is a React problem. You could theoretically rewrite React and RSC in any language and the outcome would be the same. Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.

> This isn't a Javascript problem, this is a React problem.

It happened with Next.js as well https://github.com/vercel/next.js/discussions/11106

> Say Python ran in the browser natively, and you reimplented React on browser and server in Python. Same problem, not Javascript.

Yes.

And since Python does not natively run in the browser, that mistake never happens. With JavaScript, the desire to have "backend and frontend in a single codebase" requires active resistance.

Re: Denial of service and source code exposure in React Server Components

#76

Post by TZubiri »

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…

I had this issue with a React app I inherited, there was a .env with credentials, and I couldn't figure out whether it was being read from the frontend or the backend.

So I ran a static analysis (grep) on the apk generated and

points light at face dramatically

the credentials were inside the frontend!

Re: Denial of service and source code exposure in React Server Components

#77

Post by TZubiri »

tagraves wrote: post #13

It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

Very standard in security, announcements always always always try to downplay their severity.

Re: Denial of service and source code exposure in React Server Components

#78

Post by TZubiri »

hollowturtle wrote: post #50

Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated

But the react-components are a separate library, they are not installed by default

Re: Denial of service and source code exposure in React Server Components

#79

Post by rickhanlonii »

TZubiri wrote: post #77
tagraves wrote: post #13

It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities." Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.

Very standard in security, announcements always always always try to downplay their severity.

fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.

Re: Denial of service and source code exposure in React Server Components

#80

Post by hollowturtle »

TZubiri wrote: post #78
hollowturtle wrote: post #50

Wouldn't make more sense keeping React smaller and left those features to frameworks? I liked it more when it was marketed as the View in MVC. Surely can still be used like that today but it still feels bloated

But the react-components are a separate library, they are not installed by default

? afaik react server components made it to core
Post reply on HN