151–160 of 276 posts
Earlier quoted context omitted.
We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue. We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.
Does AWS WAF have a mitigation in place?
JavaScript is meant to be run in a browser. Not on a backend server [1]. Those who are choosing JS for the backend are irresponsible stewards of their customers' data. 1- https://ashishb.net/tech/javascript/
Earlier quoted context omitted.
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.
why is it not normal for CI pipelines to cache these things? its a huge waste of compute and network.
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 agree. Incoming hot take. IMO, a big part of it is the lack of competition (in approach) exacerbated by the inability to provide alternatives due to technical/syntactical limitations of JavaScript itself. Vue, Svelte, Angular, Ripple - anything other than React-y JSX based frameworks require custom compilers, custom file-types and custom LSPs/extensions to work with. React/JSX frameworks have preferential treatment…
In my opinion, the core functionality of React (view rendering) is actually good and is why it cannot be unseated.
I remember looking for a DOM library:
- dojo: not for me
- prototype.js: not for me
- MooTools: not for me
- jQuery: something I liked finally
Well, guess what library won. After I adopted jQuery, I completely stopped looking for other DOM libraries.
But I still needed a template rendering library:
- Mustache.js: not for me
- Handlebars.js: not for me
- Embedded JavaScript Templates: not for me
- XML with XSLT: not for me
- AngularJS: really disliked it SOO much*
- Knockout.js: not for me
- Backbone.js with template engine: not for me and actually it was getting popular and I really wished it would just go away at the time**
- React: something I actually liked
You must remember that when React came out, you needed a JSX transpiler too, at a time when few people even used transpilers. This was a far bigger obstacle than these days IMO.
Which leads to my hot take: core React is just really good. I really like writing core React/JSX code and I think most people do too. If someone wrote a better React, I don’t think the problem you mentioned would hamper adoption.
The problems come when you leave React’s core competency. Its state management has never been great. Although not a React project itself, I hated Redux (from just reading its docs). I think RSC at the current moment is a disaster — so many pain points.
I think that’s where we are going to see the next innovation. I don’t think anyone is going to unseat React or JSX itself for rendering templates. No one unseated jQuery for DOM manipulation — rather we just moved entirely away from DOM manipulation.
*I spent 30 minutes learning AngularJS and then decided “I’m never going to want to see this library again.” Lo and behold they abandoned their entire approach and rewrote Angular for v2 so I guess I was right.
**It went away and thankfully I avoided having to ever learn Backbone.js.
I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc
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
> In remote procedure call systems, client-side stub code must be generated and linked into a client before a remote procedure call can be done. This code may be either statically linked into the client or linked in at run-time via dynamic linking with libraries available locally or over a network file system. In either the case of static or dynamic linking, the specific code to handle an RPC must be available to the client machine in compiled form... Dynamic stub loading is used only when code for a needed stub is not already available. The argument and return types specified in the remote interfaces are made available using the same mechanism. Loading arbitrary classes into clients or servers presents a potential security problem;
https://pdos.csail.mit.edu/archive/6.824-2009/papers/waldo-r...
Do you really need React Server Conponents or even Server Side Rendering?
Before SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server) With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend s…
Earlier quoted context omitted.
It sounds related to me. The react.dev blog post [1] says that the vulnerability is > a flaw in how React decodes payloads sent to React Server Function endpoints and the react.dev docs for React Server Functions [2] say that > Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive So it certainly…
No. You cannot find all vulnerable code by grepping for ”use server”, for instance.