Earlier quoted context omitted.
Log4j almost seemed like it
Seems subjective and a personal interpretation.
I mean yeah
RCE Vulnerability in React and Next.js
251–260 of 276 posts
Re: RCE Vulnerability in React and Next.js
#252Earlier quoted context omitted.
I couldn't agree more. I'll probably switch from React to something like ArrowJS in my personal work: https://www.arrow-js.com/docs/ It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for…
Nobody is using Redux any more, and it's even publically discouraged by the creator. It's a legacy system and including it in your problems list just makes me think you have no React experience and no idea what you are talking about (beyond technical yapping also Redux as a product still achieved what it tried to solve so your dx doesn't even matter). Firebase in this context is just a database and how you poll data…
Hi. I'm the current Redux maintainer, and have been since Dan handed it over to me in mid-2016, one year after he created Redux. It's also worth noting that Dan never used Redux on a real app (that I know of), whereas I've spent years maintaining Redux and Redux Toolkit and designing APIs based on the needs of our users.
Redux is still by far the most widely-used state management library in React apps. Some of that _is_ legacy usage, sure. But, our modern Redux Toolkit package has ~30M downloads a month. Zustand has become very popular as a client-side state option, and React Query is now the default standard data fetching tool, but you can see that even just RTK is still right up there in monthly NPM downloads:
- https://npm-stat.com/charts.html?package=redux&package=%40re...
I've frequently talked about the original reasons for Redux's creation, which of those are still relevant, and why Redux is still a very valid option to choose even for greenfield projects today:
- https://blog.isquaredsoftware.com/2024/07/presentations-why-...
Re: RCE Vulnerability in React and Next.js
#253Re: RCE Vulnerability in React and Next.js
#254Earlier quoted context omitted.
No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.) React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects. Eco…
> You don't think the rewrite to TS did not bring any value? I mean, I don't really like TypeScript, and I never have. It's ugly, boilerplatey, and inelegant. I am not a fan. So... no. But, again, some battles you have to accept you've lost. TS is everywhere and there's not much getting away from it.
[deleted]
Re: RCE Vulnerability in React and Next.js
#255Earlier quoted context omitted.
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
I'll second that Angular provides a great experience these days, but they have definitely had substantial API changes within the last few years: standalone components, swapping WebPack for esbuild, the new control-flow syntax, the new unit-test runner, etc...
Was going to say, I only vaguely look at Angular code from adjacent projects at work, and noticed all of a sudden the entire structure changed with the ngModule deprecation thing. Glad I'm not knee-deep in that.
Re: RCE Vulnerability in React and Next.js
#256Earlier quoted context omitted.
No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.) React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects. Eco…
> You don't think the rewrite to TS did not bring any value? I mean, I don't really like TypeScript, and I never have. It's ugly, boilerplatey, and inelegant. I am not a fan. So... no. But, again, some battles you have to accept you've lost. TS is everywhere and there's not much getting away from it.
I think JS is still overall more popular than TS, but if your team forces TS then yeah. It's like Java devs reluctantly switched to JS and were like, this needs more boilerplate.
Re: RCE Vulnerability in React and Next.js
#257This 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.
Curious, not critical: got links to the warnings that were given about this approach over the years?
I’m interested in learning more about the history here.
Re: RCE Vulnerability in React and Next.js
#258So this can be avoided by using react like a normal person... client side rendering + bundled with vite
Re: RCE Vulnerability in React and Next.js
#259This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…
Yghhhvv
Re: RCE Vulnerability in React and Next.js
#260This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…
while(true){
console.log("jsjs")
}