Reflecting on React Native
By this time, we expect most of you have read or heard about Airbnb's decision to retire React Native (RN) as a technology from their stack. Because we’re adopting RN more and more in our products – and we’ve been using Airbnb as a protagonist of the RN use case – we want to express our views and aid in the discussion.
The following is an excerpt of a memo initially intended for internal use at November Five. The memo was written as a reaction to a series of blog posts published by Airbnb concerning the future of React Native in their development stack. Since many of the software development companies out there will be asking themselves the same questions, we wanted to publish our take on things. We hope this memo can trigger or inspire the conversation in your team!
This extensive 5-part blog post series contains a lot of insight into Airbnb as a software company, how they look(ed) at RN as a technology, how they organised their development teams around it, and their learnings from it all.
In this post, we first want to address the Airbnb story and to then see what we can learn from it to move forward.
1. Airbnb as early adopters
Airbnb was one of the first large Silicon Valley companies to adopt RN with vigor. However, from their posts we learn that they have been struggling to adopt modern JS tooling, which are now common in JS development community. For instance, Type Checker tools like Flow or the ones baked into TypeScript. At November Five, Flow is the default today; and given the successes Microsoft is having with Typescript, these tools must not be neglected to ensure quality in our implementations.
Being early adopters, Airbnb also invested in building out client side infrastructure code and even forking React Native to remain DRY. But these features are now becoming an inhibitor to adopting new tooling, framework updates, etc. This is one of the main reasons why they are not considering other cross-platform technologies (but instead are looking into developing their own patterns to share across platforms, MvRx).
2. Perception of Airbnb tech stack
What came as a surprise to us, is that Airbnb was not aiming to go all-in on RN for their apps in the first place. Only 10-20% of their codebase was/is React Native. Their involvement in the RN ecosystem created the perception that everything was React Native in their client apps.
However, Airbnb has issues finding talent for their mostly native codebase(s). In this light, we can understand that redeveloping 10-20% of their codebase to attract new talent is a feasible investment for a company like Airbnb.
And an elaborate announcement of their “exit” will undoubtedly attract new blood into their dev ranks. As decent open source citizens and considering the role they played in the RN ecosystem, they owe the community a decent explanation on the “why”. But we can already see the HR message shining through ;) As they said themselves: React Native is polarizing, so exiting RN will attract the opposing group of engineers. Just read the comments on the tweets or reddits and you can see their strategy working.
3. Govern your bridges
“Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable with, which can lead to unideal code.”
With a team of 122 developers committing to the Airbnb client codebase, they need clear governance of what should be JS code and what should be bridged. This is a learning we must take into account.
A product must have a vision on how to organise its own shared codebase vs native codebase. The engineer implementing a piece of code should not make the call solely on his/her own expertise, but should always take the product’s vision into account. Additionally, November Five’s engineering team is only a fraction of Airbnb’s, and that makes it much easier for us to define and implement such a vision.
Our ambition must be to enable all client engineers to learn, understand and create expertise on React Native and JS development, to implement the feature in the correct environment. Or to be able to spar with a colleague to get the “right” expertise at that point in time.
This is a different approach compared to a few years ago, when a single developer owned his or her platform for a project. Today, each of our squads are equipped to operate on both sides of the bridge. And it’s because of our extensive native capabilities (and high expectations) that we’re strongly suited to make the right decisions, define better bridges and push experiences further. We really believe we need to embrace the important role of native expertise when building React Native products.
4. Taking a step back
Let’s not forget that Airbnb is not the only “major” company out there adopting React Native. Other significant companies are having big successes with React Native:
- Instagram is replacing all webviews with React Native for performance reasons. And with that experience, pushing React Native forward in their product.
- Pinterest has done a large test to incorporate RN in their application and are pushing ahead with it.
Airbnb might be out of the RN game by next year, but other companies are booking great progress with React Native as a core technology. We didn’t jump on the RN bandwagon from day 1 due to the hype factor (and we’re still glad we didn’t), so we don’t need to bail out because of this one, either.
And React Native is a fast-moving animal in itself: the Roadmap is promising, addressing many of the current key issues Airbnb and the community at large are pointing out.
5. Successes with React Native
From the posts, we can also see the good parts of working with this technology. Airbnb’s expectations were high, and they have achieved many goals that sit high on everyone’s list. A few examples:
Proof of code reuse Cross-Platform between iOS and Android.
“Most features that used React Native were able to achieve 95–100% shared code; only 0.2% of files were platform-specific (.android.js/.ios.js).”
A Unified Design Language System (DLS) is easy to achieve with RN and yields a larger shared codebase. Products like Spencer, where we have our own DSL across platforms, can heavily benefit from this.
Iteration speed. Technology like code push can be a gamechanger to ease App Store submits and upgrade scenario’s. According to the blog, Airbnb reliably used hot reloading to test their changes on Android and iOS “in just a second or two.”
Frustration drives innovation: tools like Yoga give a new take on rendering layouts with better performance.
“One of the largest concerns around React Native was its performance. However, in practice, this was rarely a problem.”
To us, this is an important one, as it is often used by engineers challenging RN on this aspect. Pragmatism wins!
Even with their setbacks, Airbnb succeeded to complete features on average at 150% of the time of 1 platform, meaning 50% faster then implementing a feature twice!
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.
Our goal at November Five and Spencer is to leverage cross-platform code sharing in our products to reduce the estimation, development, maintenance and bug fixing effort. We find React Native works well for those goals. At the same time, it also enables engineers with different backgrounds to use each other’s code and communicate with the same concepts and patterns.
As always, we are still challenging our technological choices. Our eyes will never be closed to other technologies in this space, like Kotlin MultiPlatform, Flutter and Xamarin, which are under assessment or even active development at November Five.
But today we recognise that React Native has a very strong ecosystem and is the most mature platform to achieve the above mentioned goals. But – just as we’ve always said – it’s not a silver bullet for all use cases. Companies will make decisions about their technology stack, just as we do about ours.
So let’s not confuse Airbnb’s exit as a failure of React Native. Take in the nuances of (1) building an engineering team in a place like San Francisco, (2) being the early adopter and (3) the choices they made in the past. All factors leading to their conclusion, for their product.
For each product we’ll continue to decide, consult & debate which technologies to choose before implementation – just as we did before. And as long as React Native fits the products we’re building, it will be a technology November Five will invest in, push for and educate in.
Are you triggered by our thoughts? Do you strongly agree or disagree? We are open to discussion.