Over the last 5 years, we found that these initial principles have made building some features harder. An asynchronous bridge means you can’t integrate JavaScript logic directly with many native APIs expecting synchronous answers. A batched bridge that queues native calls means it’s harder to have React Native apps call into functions that are implemented natively.
Looks like they are opting out to use their own framework that they have developed that suits their needs more. I find that this is a point of growth that even facebook have done for themselves with react native. But it’s a good thing (not much far from awesome) that Airbnb could use react native to carry them this far along the way. It’s also great for the community that they’ve shared their experience, because it points out specifics that react native and the community can implement upon.
I’m not sure this means that much. Having a 100% native ios and android app was always better than react-native, nobody argued that. For companies who are not airbnb/google/apple/uber, react-native still makes business sense for 8/10 apps.
Native will always be better if you have the resources. RN was supposed to allow write-once deploy anywhere. It separates UI (i.e. DOM if using Web) from JS logic as UI rendering used to be an issue in the past. Now we have more performant webviews. I don’t think that separation is needed anymore. Cordova works great now for all practical purposes.
AirBnB dropping RN, I think their experience with RN is more of a cultural thing than a technical one. RN isn’t “Write Once, Run Everywhere”. RN is “Learn Once, Write Everywhere” - which makes code sharing 80% with 20% platform specific code in most apps.