Post Processing: Facebook Reacts

In my post Swift vs Kotlin, I wrote how the pursuit of "one codebase to rule them all" sometimes doesn't end well. Experience has shown me this, and DropBox also shared the same hard won lesson.  Now it's Facebook's turn.

Facebook's framework -- React Native -- allows you to create native apps for Android and iOS, and proudly carries the catch phrase Learn once, write anywhere. The hidden costs, however, were code bloat, low performance, and increasing maintenance.

When I first heard of React Native, it was from positive press that declared it, without any sense of irony, "one of the best things to come out of Facebook."  But in 2018, AirBnb wrote in Medium that it was retiring its use of React Native:

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.

Other developers began to wonder if they should drop React Native as well, and Braus Blog tried to give some guidance in his post Airbnb is Dropping React Native — Should You Too?  Wonder turned into concern about Facebook dropping support, but that hasn't happened.  But what did happen was that Facebook rewrote its Messenger App to make it faster, smaller, and simpler.  Without actually saying it dropped React Native, Facebook highlighted four principles in its rewrite:  Use the OS, reuse the UI, leverage the SQLite database, and push to the server.

The first principle,  use the OS, meant Facebook went native, and mobile app developers committed to the React Native framework could only feel betrayed.  

Comments

Popular posts from this blog

Post Processing: Swift, Kotlin, Team Scaling Fallacy, Levandowski

Programmer Humor for the Holidays

Symmetry