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.
If there are so many React developers out there using server side components while not familiar with the concept of CVEs, we’re in very serious trouble.
It's ok, you gotta play the game. I'm more concerned about the fact that the downtime issue ranks higher than the security issue. But I'm assuming it relates to the specifics of the issue rather than reflecting on the priorities of the project as a whole.
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.
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.
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.
First off, thanks for all the work! I have a few questions if thats ok:
1. What is the next thing that the team wants to focus on improving?
2. What are the performance differences between the old architecture & new one?
3. What are your thoughts on the fragmented state of rn wrt react-native-web/react-native-windows/react-native-macos?
4. It is quite difficult to know what supports RN vs what relies on react-dom. Is there any thought to create some ecosystem focused around RN? Or if something like that is too cumbersone, perhaps even just adding some badge to github pages for "Supports RN"?
5. I forget what it was called, but the creator of react-native-web stated that they wanted to start winding down support in favor of an alternate approach which attempts to bring web apis to native instead of trying to make the native api work on web. I.e. instantiate div elements in native instead of view. What are your thoughts on this?
6. React (and IMO Meta as a whole) seems to generally have had the tech philosophy of take what you want, leave what you dont. With the dropping of create-react-app and endorsement of frameworks like Expo, it seems like its getting harder to just take the pieces we want. Is there any thought about this trend?
7. Related: as for the upgrade process: it would be cool if there were a way to "opt-in" to auto upgrades. E.g. what if there were a package which contained a base class controlled by the RN team so that a client side upgrade could be as simple as updating the version of the library the base class is in? (customization would be simple extending the class and doing w/e else needed there)
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.
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.
Thank you! Slightly off topic but every time new Xcode versions happen or as a result of time passing I always seem to get a messed up/corrupted Xcode project and so I end up copying the src folder and create a new project usually with an updated React Native version. This can be a real pain to be honest, taking sometimes a day or two of messing around with package version compatibility hell.
Is there a plan to fix this flakiness that I experience every 3 months or so?
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.
Maybe I can un-eject given the plugins system from Expo. I do not like the way they throw all your code around though and I think this ability to steal peoples work given the prevalence of LLMs to unobsfuscate code is problematic. You should consider providing a way to drop the bundle in in byte code or something too... while I'm writing out my laundry list of issues ;-)
Seriously, thanks for all your (and team's) hard work, I look forward to all my packages being on the new architecture and upgrading!
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.
If I had the choice of 'write a tool' or 'write a test'... I'd always pick write a test. Of course, that's me... which is why I asked the question in the first place. I was trying to understand their use case.
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!
Is that it? Facebook is a huge corporation, that must have React app after React app using Jest, and they are paying volunteers to work on it now? With a fraction of what a single developers average salary is?
They are providing their code to you free of charge. They are already doing you a kindness. So certainly they are under no obligation to spend $22k, let alone more than that. Christ, attitudes towards open source have become seriously warped over the last few years.
I will point out, as an open source maintainer: someone giving you code "free of charge" is the same thing as them giving you a free puppy: everybody loves puppies, but they are absolutely not free to maintain.
This isn't meant to imply that Meta is, in this instance, offloading costs onto the community. But it's a tried-and-true tradition.
A white elephant, basically, you mean? I definitely understand that, but I'm not sure it applies here. Jest and React are exceptionally mature and well-maintained pieces of software. Many a startup has been built by gluing React to Express and Postgres with nary a glimmer of skill required. Hell, it has its own developer tools built into Chrome.
The pernicious thing about "mature and well-maintained" pieces of software is that their maintenance becomes bursty: they don't need anything for years, until something needs changing/fixing this instant.
Log4j is the canonical example of this: it's such a boring piece of substrate that nobody noticed that it was effectively maintained by one person and had grown all kinds of configurable knobs and dials over the years.
Ultimately, I'm not saying that Meta is in the wrong here. But "here's a cash infusion with no long-term funding or staff commitment" is the kind of general mispattern that we're seeing w/r/t corporate open source.
I just don't see how it's less valuable than not using it. That seems analytically true to me: if ever the debits do outweigh the credits, then one simply doesn't use it. After all, it's not like it's a library doing some magical thing; it's a framework which operates on code written to a certain interface, and for which alternative 'compilers' (e.g. Preact) already exist.
And? They were presumably paying at one point their own developers full time salaries while working on Jest and now Jest has been cast off to somewhere else and suddenly any expected future contributors deserve, in comparison, pennies? All while still using Jest themselves internally.
> any expected future contributors deserve, in comparison, pennies?
No, they don't deserve pennies. Facebook has given its code to the world - if anyone wants to keep that code maintained, then they can do so, but (I'd have thought needless to say) Facebook does not owe them a penny to maintain it just because they were kind enough to donate that version of their code. They can update it if they benefit from doing so.
Seriously, is this where we've got to? You can't open source your code unless you're able to pay for its maintenance in perpetuity? How is this in the spirit of openness? And, more to the point, how in the hell does this (incomprehensibly entitled) attitude encourage open source development?
And good for them, but that doesn't affect the fact that they are doing you (/me, us) a favour, an act of supererogation.
In any case, my point isn't really about whether they are being kind or not. That's a fortiori. It's that they certainly aren't under any obligation to provide it, nor to maintain it on account of having provided it.
(Although to respond to your precise point: I'm severely doubtful of your claim that Facebook gets 'huge marketing PR' from an open source library. No one is signing up to Facebook because of the [apparently-existent] 'huge marketing' of the fact that they wrote React.)
This isn't some_one_, it's some_thing_. I share your sentiment when it comes to individuals but extending the same sympathy to a company, especially one the size of Facebook, doesn't make sense imo.
It's not a question of 'sympathy', it's a question of recognising the neutral fact that a company providing its code to you free of charge is not further obligated - irrespective of whether you happen to like or dislike that company - to spend what you deem to be an 'appropriate' amount on maintaining the free software they provide you.
(And, even if any of the foregoing made any sense, the notion that an 'appropriate' amount is somehow measured relative to the company's revenue, rather than the factual costs of maintaining the software, is disqualifyingly silly in its own right.)
This isn't some random small library. It is/was a library developed by a FAANG company that underpins a large part of the JS ecosystem that they were paying their full time employees to work on.
I didn't know they had so little donations. It's a super important building block of the industry, and yet the industry doesn't even pay a single developers salary for it?
Why would anyone else in the industry contribute resource to a FB-owned project with closed governance? They are in the bottom five companies in the world that need help with the open source projects they maintain.
I get what you are lamenting in general, I would like to see OpenSSL or Django or perhaps even Linux better funded for example. It just seems to me that this is not a case where any lamenting is justified. If the newly-community-owned Jest doesn’t get investment, then sure, that would be lamentable. But that hasn’t happened yet. Indeed, FB divesting ownership was a necessary condition for any serious outside investment to occur, IMO.
I was talking about the Linux Foundation of the original comment.
Now reading back, I realise that I might have gotten confused and took the numbers that were referring to the Facebook project, thinking it was the Linux donations.
