Article

^{Chain React 2018 was hosted in Portland, Oregon from July 11th-13th by Infinite Red. It was a wonderfully well-organized event with an excellent selection of speakers who covered a wide range of interesting topics. Videos of all of the talks are available on YouTube courtesy of Infinite Red. Or if you don’t have time for that, you can read a nice recap of both days here and here.} 

Recently during a talk at the 2nd annual Chain React conference, Ori Harel asked how many people came from the native side of mobile development as opposed to JavaScript/web. I was surprised to see that roughly 50% of the room raised their hands. I suppose my perspective was limited to my own experiences as a web developer, but I had previously held this notion that React Native was simply a shortcut for JavaScript developers like me to develop mobile apps without having to learn anything new. 

While that is certainly part of the appeal for many people (myself included), I soon began to realize that the value of React Native is not as a substitute or replacement for native development, but as a means for cross-functional teams to share part of their codebase with their cross-platform (iOS vs. Android) and web counterparts. And Indeed, it appears that many native developers are embracing this technology rather than turning up their noses at it (more on Airbnb later), which clears an adoption hurdle that I would consider to be React Native’s greatest challenge. In the JavaScript world, with its constant stream of new frameworks cycling in and out of relevance, this is as much assurance as you can get that React Native is not just some fad that could “lose” and go away.

React Native for cross-functional teams

Robert Scarano discussed in his talk how Squarespace implemented React Native across functional teams, arriving at something that essentially amounted to “write 1.5 times, reuse on 3 platforms." He described the process and patterns used to refactor the same application written three times into about 30% web-and-mobile-specific code vs. 70% shared code. While “write 1.5 times, reuse on 3 platforms” is not exactly the Holy Grail “write once, run anywhere” of Java, “write once, run anywhere” is precisely what React Native is not chasing according to its introduction blog post on the React JS website in 2015. The author goes on to explain that “different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform." 

Instead, the niche that React Native has carved for itself is an intersection where iOS, Android, and web developers can coexist and enjoy the efficiencies of a shared codebase. The idea, then, is for the framework not to disrupt the mobile development ecosystem but to add to it. This gives the framework an even better shot at longevity, as it is not competing to supplant current technologies. In fact, the only “competitor” that has emerged so far is Vue Native, which is nothing more than a Vue wrapper around React Native’s core.

What about Airbnb?

This is not to say that the framework has not had its share of difficulties. Airbnb, one of the largest and most prominent companies to adopt the technology, famously shook the React Native world last month when they announced in a 5-part blog post that they will be sunsetting React Native and transitioning back to native. The blog post offers an honest assessment of the Airbnb team’s experiences with the technology, highlighting many of the positive aspects and acknowledging that “. . . React Native is revolutionary in many ways . . . it is a paradigm shift for mobile and we were able to reap the benefits of many of its goals . . .” but ultimately delving into the combination of technological and organizational problems that led to the decision to discontinue its use. This move has many in the community questioning the future of the platform. And while it does have some immediate consequences, like the loss of a major contributor to the ecosystem with tools like Native Navigation and Lottie for React Native, as well as contributions to the React Native core itself, this does not in any way mean the death or decline of the popular framework.

Thankfully, Airbnb’s blog post generously provides detailed explanations of both the technical and organizational factors that contributed to their decision, and the React Native community has already set to analyzing the deficiencies and gleaning any useful insight (watch a group of Chain React panelists offer their opinions on the matter). More time may need to pass before we know what history will ultimately make of all this, but the community at large seems to be echoing the same sentiment (and this may be a case of “hindsight is 20/20”): that introducing React Native into this project was probably not the right choice based on a variety of reasons, but largely that “brownfield” can be extremely difficult for a large, complex app like Airbnb’s.

Speaker Harry Tormey, perhaps as a direct response to the Airbnb situation, discussed considerations and strategies for using React Native in a brownfield app. He explained that this scenario would be bested suited for large organizations (check) that have multiple teams working on the same app for multiple platforms (check), and ideally organizations that have a web team that already uses React (check). He was careful to emphasize that a brownfield app is roughly 2 to 3 times harder than a greenfield app, and that choosing the wrong project could potentially nullify many of the advantages of React Native (check). 

According to Tormey, the successful adoption of a new technology relies heavily on building trust for the new technology, so an organization’s first brownfield project should be something simple and quantifiable. Starting small and building momentum on small successes allows an organization to build faith and ensure the buy-in of individuals and teams, not to mention manageably traverse the landscape of potential technological pitfalls. It should not be surprising, then, that Airbnb had the level of difficulties that it did. And while this could be considered a major setback for the React Native world, it will hopefully serve as an important lesson that will strengthen the community and inform the shape of things to come.

The future of React Native

Despite the loss of Airbnb, the React Native community appears ready to continue onward and upward. In a blog post published just 5 days before the Airbnb news dropped, Facebook announced a major rearchitecture of many of React Native’s internals to improve integration with native infrastructure, addressing a common pain point for many people and what turned out to be a large contributing factor to Airbnb’s decision on the technological side. It should be interesting to see how these changes affect the developer experience, presumably for the better. This along with continued efforts from the React Native community give me confidence that this flexible platform will continue on as fundamental part of the mobile development ecosystem.