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

RCE Vulnerability in React and Next.js

github.com

Post reply on HN
Print view View original

61–70 of 276 posts

Re: RCE Vulnerability in React and Next.js

#61

Post by halflife »

paulhebert wrote: post #56
halflife wrote: post #54

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 compile…

I wish React wasn’t the “default” framework. I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated.

And what they DO add? Only things that improve dev exp

Re: RCE Vulnerability in React and Next.js

#62

Post by IceDane »

javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

Not even remotely similar.

Re: RCE Vulnerability in React and Next.js

#63

Post by danabramov »

halflife wrote: post #54

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 compile…

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 (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.

Re: RCE Vulnerability in React and Next.js

#64

Post by samdoesnothing »

This is genuinely embarrassing for the Next.js and React teams. They were warned for years that their approach to server-client communication had risks, derided and ignored everyone who didn't provide unconditional praise, and now this.

I think their time as Javascript thought leaders is past due.

Re: RCE Vulnerability in React and Next.js

#66

Post by wepple »

IceDane wrote: post #62
javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

Not even remotely similar.

Care to elaborate on what it is like, then?

Re: RCE Vulnerability in React and Next.js

#67

Post by mvdtnz »

javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.

Re: RCE Vulnerability in React and Next.js

#68

Post by mvdtnz »

IceDane wrote: post #62
javaking wrote: post #32

I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb

Not even remotely similar.

Actually he's more or less correct.

Re: RCE Vulnerability in React and Next.js

#70

Post by korm »

root_axis wrote: post #59
ascorbic wrote: post #28

Earlier quoted context omitted.

That number is misleadingly low, because it doesn't include Next.js which bundles the dependency. Almost all usage in the wild will be Next.js, plus a few using the experimental React Router support.

As far as I'm aware, transitive dependencies are counted in this number. So when you npm install next.js, the download count for everything in its dependency tree gets incremented. Beyond that, I think there is good reason to believe that the number is inflated due to automated downloads from things like CI pipelines, where hundreds or thousands of downloads might only represent a single instance in the wild.

It's not a transitive dependency, it's just literally bundled into nextjs, I'm guessing to avoid issues with fragile builds.
Post reply on HN