Why React Native Part Five

Meanwhile at Facebook...

Tracking Facebook’s mobile development approaches over the last 10 years gives us a good understanding of the industry as a whole. In the early days, Facebook was a webpage, so it stood to reason that they would want to use hybrid web technology to allow for mobile use. And that’s what they did, twice. The first time was their responsive website which worked fine for mobile smart phones and, at the time, “dumb” phones too. And the second time, when they created a hybrid mobile app which used a native frame to wrap an embedded webpage that would run the same on both devices. In other words, it was a webpage wrapped in an app that resulted in a 2-star rating, with speed and stability issues. No matter what they did, they simply could not get the app to feel native on mobile devices using web technologies.

Eventually, accepting that a hybrid app wasn’t going to work for then, they started from scratch with a native app on four different platforms (web, iOS, Android, and Windows Mobile). This meant they would need four different teams and those four teams would need to work to maintain consistency across all platforms. But that was the smaller problem (and they had the money and resources to do it). The bigger issue was trying to make a web-based app ‘feel’ native. When the new app was released, it was immediately noticeable that they had made it work and the app ratings soared to 4+ stars.

Around this same time their web tools team was working on a new framework called React. React simplified how the presentation layer of the website worked on all the many different screen sizes that needed to be supported across both desktop and mobile browsers. It was a hit with the web community and since React worked so well on the mobile website, it naturally led developers to ask, what if we used this framework on native mobile apps as well? Not rendering React inside a web view, but rather using the React framework to drive how the interface was built inside the native app, rendered with native components.

This idea was presented at the Facebook hackathon in the Summer of 2013. And just a year and a half later, in January of 2015, React Native was announced. The initial response was good, but most native developers had been bitten in the past by promises of hybrid solutions, so most of the adoption came from the React web community. However, that community expanded very quickly and by September 2016 Google trends showed React Native overtaking both Android and iOS developer-based searches.

There were two main features that helped in this growth. The first being that the framework was based on React and JavaScript, two proven technologies that many developers already knew and were comfortable using. The second was that the apps it created were still native and didn’t use web views to render the interface and you could therefore drop back to native code whenever you needed.

In part six we’ll take a closer look at JavaScript and React for web versus JavaScript and React-Native for mobile to see how this works in practice.

More News

| 10th Dec 2018

Curriculums Aren’t Just for School Anymore

Selections from the CTO’s library and Isobar's core curriculum.

| 29th Nov 2018

Isobar: A Community of Free Electrons

Javier Frank explores a special type of overachiever developer.

| 20th Nov 2018

How React Native Was Was Used for the Get WIRED App

The latest in our React Native series takes a look at the Get WIRED app.