What is the plan for React Native Web given RSD?

[ghost]

Now that React Strict Dom is released, @necolas, it'd be great to hear what you have in mind for React Native Web.

Will development be continued? Will 0.20 be released? What approach do you recommend for new projects?

I've seen discussion on Using RSD for web-only apps, but I'm unsure of how far from production ready the native part is, and it's worth having discussion here about plans for RNW.

[efoken]

I think React Native for Web should be based on RSD, but still exporting all the React Native components like View, ScrollView, etc. And stuff like FlatLists, which are in an extra React Native package can also be directly built with RSD.

So in the end React Native for Web would only be a very thin layer which can be used, but is not mandatory to use.

[necolas]

My personal opinions...

What approach do you recommend for new projects?

I think new projects should use RSD as much as possible. It increases the incentives for RN feature development aligned with web APIs, and ensures that the web experience is as good as you can get with React. There is no investment at Meta in RNfWeb by either the Web or RN teams, whereas both have been working on RSD.

Will [RNfWeb] development be continued?

I will continue to review PRs and merge fixes. But I don't expect to put significant time into major development initiatives.

I'm unsure of how far from production ready the native part is...

I think it's production ready. The native part is driven by existing RN APIs, and the newer web APIs in RN are already used in production by Meta.

I think React Native for Web should be based on RSD...

That would require a lot of work and changes only for RNfWeb to still have to layer on all the transforms needed to match RN's non-standard APIs. I can't really see the benefit given the cost involved and the issues it would create for existing RNfWeb users. RSD on Web is just RDOM + StyleX.

---

Edit: I also want to add (given something that was said at React Conf 2024) that using RNfWeb to bring existing RN apps to Web is not a good use case. We tried this internally at Meta and found that RN apps are simply missing too much semantic information to produce quality web apps as output.

RNfWeb has always had the expectation that it be used for web-first development, where the extra semantics it provides for web simply no-op on native. This is exactly the same development paradigm that Microsoft have for RNfWindows - you can't simply run an existing RN mobile app on Windows, you need to use the RNfWindows API extensions otherwise you get no mouse support, no multi-window support, etc. This is one of the fundamental problems with React Native's JS API today - it's not a cross-platform library. And that's the reason why I started React Strict DOM; the API RSD provides has the built-in semantics needed for web apps, windows apps, etc. This makes it far easier to adopt as a general cross-platform API - you don't have to first pick the right "flavor" of React Native for the primary platform you're targeting.

So the idea that you can pick either RSD or RN JS to author cross-platform apps is incorrect. This was the hope a couple of years ago when I first started trying to get RN to "reduce fragmentation" by aligning itself with web, but each small change triggers a slow and costly migration effort. I now think it's unrealistic to expect RNfWeb to become materially smaller in the years ahead, as to do that would first require that most of the existing RN ecosystem migrate away from certain patterns like dynamically reading values from styles at runtime, using non-standard and async events, etc. There's been little progress on that front in OSS over the last 6+ years, and little incentive for us to do that internally at Meta since new cross-platform experiences are being built with RSD.

[ghost]

I think it's production ready. The native part is driven by existing RN APIs, and the newer web APIs in RN are already used in production by Meta.

Keeping in mind the JS Performance discussion, it's great to hear the APIs are functional and used in production.