• Sunsetting React Native
  • By Gabriel Peal
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: ALVINYEH
  • Proofreader: DateBro

The React Native retired

Due to various technical and organizational issues, we will stop using React Native and focus on making the Native experience better.

This is the fourth in a series of blog posts that will outline your experience with React Native and what’s next for Airbnb mobile. Where do we go today?

While many teams relied on React Native and planned to launch it in the foreseeable future, we ultimately failed to achieve our original goal. In addition, there were technical and organizational challenges we couldn’t overcome that made it more difficult to continue deploying React Native.

So let’s go ahead and officially stop using React Native at Airbnb and put all of our energy back into Native.

Failed to achieve our objectives

Iteration needs to be faster

When React Native worked as expected, engineers were able to iterate with unparalleled speed. However, many of the technical and organizational issues we’ve outlined in this blog series have added to the frustration and unexpected delays of many projects.

Maintain quality standards

Recently, as React Native has matured, we have accumulated more expertise and are now able to do a lot of things we weren’t sure about at first. We built shared element conversions, scrolling parallax, and were able to significantly improve the performance of some screens that used to lose frames. However, some technical challenges, such as initialization and asynchronous priority rendering, make it challenging to meet certain goals. Lack of internal and external resources makes this more difficult.

Write code once, not twice

Although the code in React Native is almost shareable across platforms, only a small portion of our app is React Native. In addition, a large amount of bridging infrastructure is required to enable product engineers to work effectively. Therefore, we support code on three platforms instead of two. We saw the potential for code sharing between mobile and the Web, and were able to share some NPM packages, but other than that it was never implemented in a meaningful way.

Improving the Developer experience

React Native’s developer experience is very different. In some areas, such as build time, things are much better. However, in other areas, such as debugging, the situation is worse. Part 2 of this series Outlines the details.

Retirement plan

Unable to achieve our specific goals, we made the difficult decision that React Native was no longer for us. We are currently working with the team on a healthy transition plan. We’ve stopped all new React Native features and plan to convert most of the highest traffic view pages to Native writing by the end of the year. This is aided by some scheduled redesigns that are about to begin. Our Native infrastructure team will support React Native through 2018. In 2019, we’ll start reducing support and reduce some React Native overhead, such as the initialization runtime at startup.

At Airbnb, we’re big believers in open source software. We actively use and promote many open source projects around the world and have also opened up some of our React Native work. Since we don’t use React Native anymore, we can’t maintain the features of React Native as a community. To make the community better, we’re going to migrate some of our React Native open source work to the React-Native community. We’ve already started using React-Native maps, And will soon use native navigation and Lottie-React-native.

This is not all bad

Although we couldn’t continue to achieve our goals with React Native, the engineers who used React Native had a good experience. Among these engineers:

  • Sixty percent said their experience was amazing.
  • Twenty percent thought it was good.
  • Fifteen percent said it was bad.
  • Five percent expressed a strong negative attitude.

Given the opportunity, 63% of engineers would choose React Native again, and 74% would consider using React Native for a new project. But it’s worth noting that there is an inherent selection bias in these results, as it only surveyed people who chose to use React Native.

These engineers wrote 80,000 lines of production code and 40,000 lines of Javascript infrastructure on 220 pages. For reference, we have about 10 times the amount of code and 4 times the number of pages on each of the original platforms.

React Native is coming of age

This series of blogs really reflects our current experience with React Native. However, Facebook and the more open React Native community are working on React Native for hybrid applications. React Native is growing faster than ever. There were over 2,500 commits last year, and Facebook has just announced that they are addressing some of the technical challenges we are facing. Even if we don’t use React Native anymore, we’re excited to continue to follow these developments, because React Native’s technological advantages have brought real success to people using our products around the world.

Some think

We integrate React Native into large existing applications and continue to iterate at a very fast rate. Many of the difficulties we encountered were due to the hybrid model approach. But we have the scale to take on and solve difficult problems that smaller companies might not have the time to solve. It’s possible, but challenging, to make React Native work seamlessly with Native. Each company using React Native will have a unique experience defined by their team composition, existing applications, product requirements, and React Native maturity.

When everything comes together, React Native matches the work done by many features, the speed of iteration, the quality, and the developer experience, even exceeding all our goals and expectations. Sometimes it really feels like we’re about to change the rules of mobile development. As inspiring as these experiences are, when we balance positive emotions with the pain points of engineering organizations and their current needs and resources, we decide it’s not for us anymore.

Deciding whether or not to use a new platform is a big decision, and it all depends on your team’s unique factors. The experiences and reasons we abandoned them may not apply to your team. In fact, many companies continue to use it successfully today, and for others, it’s probably still the best choice for most companies.

While we never stopped using the original, the React Native decommissioning freed up more resources to make the original better than ever. Read on for the next installment of this series to learn about the new functionality of learning native.

This is the fourth in a series of blog posts focusing on our experience with React Native and what’s next for Airbnb mobile.

  • Part I: React Native in Airbnb
  • Part TWO: Technical details
  • Part three: Building a cross-platform mobile team
  • Part 4: Decisions made on React Native
  • Part five: What’s next on mobile

Thanks to Laura Kelly.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.