文章連結:
https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a
文章內容:
Due to a variety of technical and organizational issues, we will be
sunsetting React Native and putting all of our efforts into making native
amazing.
Jun 20, 2018 · 5 min read
This is the fourth in a series of blog posts in which we outline our
experience with React Native and what is next for mobile at Airbnb.Where are
we today?
Although many teams relied on React Native and had planned on using it for
the foreseeable future, we were ultimately unable to meet our original goals.
In addition, there were a number of technical and organizational challenges
that we were unable to overcome that would have made continuing to invest in
React Native a challenge.
As a result, moving forward, we are sunsetting React Native at Airbnb and
reinvesting all of our efforts back into native.
Failing to Reach Our Goals
Move Faster
When React Native worked as intended, engineers were able to move at an
unparalleled speed. However, the numerous technical and organizational issues
that we outlined in this series added frustrations and unexpected delays to
many projects.
Maintain the Quality Bar
Recently, as React Native matured and we accumulated more expertise, we were
able to accomplish a number of things that we weren’t sure were possible. We
built shared element transitions, parallax, and were able to dramatically
improve the performance of some screens that used to frequently drop frames.
However, some technical challenges such as initialization and the async first
render made meeting certain goals challenging. The lack of resources
internally and externally made this even more difficult.
Write Code Once Instead of Twice
Even though code in React Native features was almost entirely shared across
platforms, only a small percentage of our app was React Native. In addition,
large amounts of bridging infrastructure were required to enable product
engineers to work effectively. As a result, we wound up supporting code on
three platforms instead of two. We saw the potential for code sharing between
mobile and web and were able to share a few npm packages but beyond that, it
never materialized in a meaningful way.
Improve the Developer Experience
The developer experience with React Native was a mixed bag. In some ways,
such as build times, things were dramatically better. However, in others,
such as debugging, things were much worse. The details are enumerated in part
2 in this series.
Sunset Plan
Because we weren’t able to achieve our specific goals, we have decided that
React Native isn’t right for us anymore. We are currently in the process of
working with teams to create a healthy transition plan. We have halted all
new React Native features and have plans to transition the majority of the
highest-trafficked screens to native by the end of the year. This was aided
by some scheduled redesigns that were going to happen regardless. Our native
infrastructure team will support React Native through 2018. In 2019, we will
begin to ramp down support and reduce some of the React Native overhead such
as initializing the runtime on launch.
At Airbnb, we are strong believers in open source. We actively use and
contribute to many open source projects around the world and have open
sourced some of our React Native work as well. As we have moved away from
React Native, we haven’t been able to maintain our React Native repos as
well as the community deserves. To do what’s best for the community, we will
be migrating some of our React Native open source work to
react-native-community which we have already begun to do with
react-native-maps and will do with native-navigation and lottie-react-native.
It is not all bad
Although we weren’t able to achieve our goals with React Native, engineers
who used React Native generally had a positive experience. Of these engineers:
60% would describe their experience as amazing.
20% were slightly positive.
15% were slightly negative.
5% were strongly negative.
63% of engineers would have chosen React Native again given the chance and
74% would consider React Native for a new project. It is worth noting that
there is inherent selection bias in these results since it only surveys
people who chose to use React Native.
These engineers wrote 80,000 lines of product code across 220 screens as well
as 40,000 lines of javascript infrastructure. For reference, we have about
10x the amount of code and 4x the number of screens on each native platform.
React Native is Maturing
This series of posts reflects our experiences with React Native as of today.
However, Facebook and the broader React Native community are dedicated to
making React Native work for hybrid apps at scale. React Native is
progressing faster than ever. There have been over 2500 commits in the last
year and Facebook just announced that they are addressing some of the
technical challenges we faced head-on. Even if we will no longer be investing
in React Native, we’re excited to continue following these developments
because technical wins in React native translate to real-world wins for the
people around the world who use our products.
Takeaways
We integrated React Native into large existing apps that continued to move at
a very fast pace. Many of the difficulties we encountered were due to the
hybrid model approach we took. However, our scale allowed us to take on and
solve some difficult problems that smaller companies may not have had time to
solve. Making React Native work seamlessly with native is possible but
challenging. Every company that uses React Native will have an experience
that is a unique function of their team composition, existing app, product
requirements, and maturity of React Native.
When everything came together, which it did for many features, the iteration
speed, quality, and developer experience matched or surpassed all of our
goals and expectations. At times, it really felt like we were on the verge of
changing the game for mobile development. Even though these experiences were
highly encouraging, when we balanced the positives against the pain points
plus the current needs and resources of our Engineering organization, we
decided that it wasn’t right for us anymore.
Deciding whether to use a new platform is a major decision and depends
entirely on factors unique to your team. Our experiences and reasons for
moving away may not apply to your team. In fact, many companies are
continuing to successfully use it today and it may still be the best choice
for many others.
Although we have never stopped investing in native, sunsetting React Native
frees up even more resources to make native better than ever. Follow along in
the next part of this series to learn what’s new in native for us.
This is part four in a series of blog posts highlighting our experiences with
React Native and what’s next for mobile at Airbnb.
Part 1: React Native at Airbnb
Part 2: The Technology
Part 3: Building a Cross-Platform Mobile Team
Part 4: Making a Decision on React Native
Part 5: What’s Next for Mobile
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.167.134.108 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Programming/M.1566111874.A.EFB.html