rickhanlonii

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.

Yeah agreed, thanks again for the feedback. The priority here is clear disclosure and upgrade steps.

GitHub has to review the advisories and publish it for it to show in `npm audit`, so it's delayed.

Thanks for the feedback, I adjusted it here so the first note is related to the impacted versions:

https://github.com/reactjs/react.dev/pull/8195

After Log4Shell, additional CVEs were reported as well.

It’s common for critical CVEs to uncover follow‑up vulnerabilities because researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed.

That's a lot of questions, thanks for asking! I'll stick to answering the ones related to the new arch.

The next thing is to continue building on this foundation and fix some long standing issues things like scroll perf and text input. A lot of our focus has been on the gradual migration strategy for the new arch, so now we'll have more capacity to work on other things.

For perf differences, we shared some benchmarks here: https://github.com/reactwg/react-native-new-architecture/dis...

But perf alone doesn't really tell the whole story. In raw perf terms, flashing empty content for just one frame is only a few milliseconds, but user is disproportionally impacted by that flicker. The new arch allows us to fix those types of issue in addition to the raw perf wins.

I don't know of any Flutter comparisons, but we shared some benchmarks here: https://github.com/reactwg/react-native-new-architecture/dis...

Will do, thanks paul big fan of your work

In the post we explain that this release removes the bridge, so the JS thread calls C++ directly without a queue, serialization, or bridge: https://reactnative.dev/blog/2024/10/23/the-new-architecture...

Kind of. We already had a native UI tree running in native (the same way the browser has it's own internal representation of the DOM). The difference in this release is that we rewrote it in C++ and made it immutable. That means instead of having a different UI tree in each platform (one for iOS, one for Android, etc), we have one C++ tree that all platforms use. And since it's immutable, it's thread safe and we can read layout and commit it from different threads if needed.

Reconciliation is still done in React on the JS thread, similar to React DOM.

Yeah this is a tricky problem, and it's one of the reasons we updated our recommendation to use a framework like Expo that can make upgrades be smoother by being more opinionated about the setup.

As the core library, we need to support all the different ways React Native can be added to an app (from fully react native to adding react native to an existing app) and all the different build tools an existing app may use. So it's hard for us to be opinionated about the setup in a way that would make upgrades seamless, but a framework can solve this for you.

Capacitor is really cool because it allows you to build a web app in iOS and Android and access the platform APIs from JavaScript. The rendering layer is a bit different though, because in React Native you can use the platform APIs _and_ the platform components. In React Native, the views you render on iOS are the same UIKit UIViews that a native app would write. In Capacitor, these are DOM elements in a webview. There are different tradeoffs, but this difference is what makes React Native look and feel more native.

I helped write this post, so feel free to ask me anything about the New Architecture!

Yeah we all know what you're talking about, you don't have to explain it. Testing is not the universally correct strategy for every case, and unless you take the time to understand their use case, you're really not in a position to understand the tradeoffs or make value statements about their work.

From Jest's perspective, that amount is way over what we've needed to date.

We don't really need the funds and can't spent the ones we have, so we haven't pushed for more donations over the years.

Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.

Meta is a backer of the Linux Foundation which OpenJS is a part of and has donated $22,000 to the Jest Open Collective which was created by Meta in 2016 to support non-employee Jest contributors. Jest actually has all the funds we need right now and our bigger issue is finding ways to spend it!

I started as a Jest core contributor before joining Meta. It's arguably the reason I work there now, and I'm really excited for the move.

Meta created Jest and a lot of the features that it's known for, but it's true that it hasn't been invested in for a few years and most of the recent features were created by the community.

With this move, Meta is showing their commitment to Open Source and Jest will be able to grow with ownership through the OpenJS Foundation led by the Jest core team and the Jest community.

We don't expect most users will interact with the `startTransition` API directly. Instead, it will be built into routing libraries and other infra code so you get the benefit of transitions without need to wrap all the state updates yourself.

We plan to do this in a close follow up release! Automatic batching was one important step, because it starts to treat native events the same as events that goes through the synthetic event system. The rest will be a bigger breaking change for some folks though, so we didn't want to include it in this release, which is focused on giving users a smooth upgrade to start using concurrent features.

"Widely documented" means that it's trivial for you to look up the data yourself.

They're listening, but not to your voice or with a microphone.

Facebook is listening to your data--to all of our data, all at once. They have locations, searches, clicks, messaging, photos, hashtags, and any other form of browsing patterns for everyone in your country, everyone in your neighboorhood, everyone in the same room as you.

They have enough data with such advanced analysis that on occasion they can get really close what you're thinking/doing without you explicitly telling them. They're doing this frequently enough to creep a lot of people out and they're only going to get better at it over time.

What we have here is something like Turing test for privacy: a sufficiently advanced amount of data and analysis will be indistinguishable from surveillance.

It's simply unnecessary to listen with a microphone.

Edit: found this slide from F8 in 2015 where they said they store 300PB and process 10PB (with a P) of data per day https://www.instagram.com/p/0tUjrQKH6R

Could be shared IP or even just "target people located near people who are targets" since they have location data

I can think of a few problems with this just off the top of my head:

The first x minutes of a post are _heavily_ influential in the success of the post, editing after allows you to hijack successful titles for gain (spam)

For large subs, posts only hit the top of /new for x minutes (for small x), editing after is basically useless if it's not successful in that time

Mods patrol the /new queue as posts come in, allowing editing will complicate moderation which is already a difficult job

Great rant about something way over my head by someone who knows way more than me about it!

If I can transfer to a domain I understand better (front-end dev): It sounds like VMs, Jails, and Zones are like Ember.js: it comes with everything built in and is simple if you stay within the design.

Containers are more like React: it gives you the pieces to build it yourself, and building it all yourself can lead to complexity, bugs, and performance issues.

Disclosure: I have no idea what I'm talking about

There are certainly other reasons. For example, I only comment as an admission of failure to express my self in code. Most of the time a better variable name or adding a function with a descriptive name will say the same thing as a comment

Reset everything you don't want to assume is public

I misspoke, yes it's a function call to React.createElement

To be fair <div /> is a function when converted from jsx to js