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.
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.
It reminds me of projects being moved to the Apache foundation, that too often felt like an obituary of sorts. I'm sure there's good stewardship of those projects at Apache, but nothing exciting to come out of it.
And it's a shame. I wish there were more of these big companies that would just, idk, pay an organization like Apache or in this case OpenJS so that they can operate as a software development and open source stewardship company, pay people to work and manage these projects.
It's not about money. Foundation stewards without any attachment to the project are like political appointments; no skin in the game. Money doesn't push a projects requirements and demand it continues to evolve, diverse users do.
Sending it off to the Apache foundation in this state to me sends a signal that it's good enough, innovation is no longer required, and therefore is not worth the investment to continue to maintain.
It's going to take a while to impact the current ecosystem but NodeJS is implementing testing natively and that will inevitably erode the popularity of jest/mocha/etc -
It will have some impact, but that erosion will be limited by how readily portable it is (I’d assume very, but haven’t looked at the source) and how attractive a target it’ll be for abstractions.
The former is table stakes if it has any chance of displacing test frameworks which are already widely used for both server and client code. I would be shocked if it’s an issue though, there’s very little to gain from coupling a test framework to Node specifics (its own non-test APIs, V8 bindings, NAPI, etc) unless you’re heavily invested in that focus. (I say this as someone who’s worked on such a project off and on for a while, and even then the primary motivation is to make testing itself more portable without sacrificing performance or tooling.)
The latter—attractiveness as a low level API to build on—remains to be seen. This is something Node generally does well with its novel APIs. But it’s a very crowded space already. And from what I’ve seen looking at the APIs, they don’t offer a whole lot more than basic correctness that can be skipped to quickly prototype and iterate abstraction ideas.
Otherwise it’ll be a reasonable default for very Node-specific greenfield projects. Which is welcome! But it’s also a somewhat niche audience. Portability is going to matter to almost all Node users already, and abstraction will matter to a largely overlapping segment of users who are accustomed to a much richer set of built in and extensible testing semantics.
I don’t want to dismiss the effort or its prospects outright! I just think it’s become increasingly clear that Node’s influence relative to the JS ecosystem is shrinking as the diversity of runtimes increases and as compatibility between them becomes more important.
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.
>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.
What's the status of Rome? Is that being looked at as a long term replacement?
I'm a mixed of confused and optimistic about this project.
On one hand, I would absolutely hate for someone to force me to use one tools, opinions for everything I do in a project.
On the other hand, if I just start a new job and I need to get producing, I'd rather have one big tool that just makes JavaScript work. Versus 4 different tools with a bunch of different limitations.
I have full confidence that the people working on it can deliver an incredible product. I have severe doubts that this will be sustainable as a business though, which really sucks
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.
I obviously have, primarily the FBI's Uniform Crime Reporting (UCR), the Bureau of Justice's National Crime Victimization Survey (NCVS), and the Washington Post's police shootings database. If you compare the police-citizen homicide rate of the latter to the violent crime rate by race/ethnicity of the former, it's quite proportional.
If you're basing your opinion off of highly publicized gruesome videos, I can show you less publicized videos of other races being killed by police too.
