How to pitch React Native to Developers
This blog post is part of a series about pitching React Native to different people you may interact with. The other parts can be found here
- Developers
- Development Team Leads
- Designers (coming soon)
- Managers (coming soon)
If you read this you likely agree with me; that React Native is super awesome. It gives developers the opportunity to target platforms they otherwise wouldn’t be able to target without a significant effort in learning new languages, concepts and platforms. So you and I are on one side, how do we convince the rest of your company? Let’s see:
Other Developers
This one should be easy, right? I mean developers are always enthusiastic when it comes to new technologies. Yes and no, on the one hand, most developers are passionate about tools and languages and on the other hand, most developers are passionate about their tools and languages. Also, the Javascript ecosystem evolves so fast, that most developers have a hard time staying up to date without misunderstanding some technologies. React and especially React Native tend to be in this category quite often, so let’s deal with the most common ones:
It’s the same as Cordova, Phone Gap, … and we failed with those
This is the most common misinterpretations of React Native I have heard so far. I have personally never developed anything with those technologies, but I have heard quite a lot of swearing from people doing so. The most common problems were that the apps don’t feel “right” on any platform and that they lack performance. The problem for both lies in the architecture: They use a Web View to render the Javascript application and expose native APIs through Plugins to the Web View. There are two major problems with this approach:
- The web view doesn’t get as much power as a regular safari view, which leads to bad performance
- The web view is the same on each platform. That way you don’t need to change any application code for a new platform, but everything looks quite identical to each device.
React solves this problem differently; React uses a bridge which directly executes (Objective-C / Java) code on a separate thread. The way this works is that React computes the difference between the old UI state and the new UI state and sends this diff to the native thread. The native thread then executes native code to render the new UI state. This way no web view is needed and everything that is rendered is the same as a regular native application would do.
This approach is much more efficient and has another benefit: Because every fundamental React component is mapped (and taken from) a native counterpart the UI always looks completely platform specific and feels a lot more like a normal native application. Of course, you may tailor it, so that every platform looks completely the same if that is what you want.
Another thing React, in general, is great at is the developer experience; You get verbose warnings and errors, which help in most cases to debug the issue quickly.
Why learn Javascript instead of (Objective-C / Swift / Java)?
This may seem a bit counter-intuitive at first. You learn Javascript to write an application you could otherwise have written in Objective-C, Swift, Java or C#, where is the profit? If you already know Javascript, this isn’t a point for you, but otherwise, this may be a real problem for you. The great benefit of React is the principle “learn once, write everywhere”. By learning Javascript and React Native, you not only get the possibility to write iOS and Android Apps but also Windows Phone, Desktop, and Web Apps. It opens up a whole bunch of opportunities compared to the old school approach. To do that, you would need to learn several languages, a bunch of frameworks and not to forget to learn how to debug on each of those environments.
Apart from the learning aspects and technical know how another nice benefit of React Native is that you get to reuse code between the platforms. Of course, you won’t be able to reuse all of your code and honestly you shouldn’t aim to do so (your application will look strange with the same code for iOS as for Android), but some parts are quite easy to reuse:
- The backend facing parts (API Wrapper, Data Storage, Async Storage, Redux, etc.) can easily be reused across all platforms
- The top and mid level components may also be used across multiple devices, especially if you tend to build small components
Please bear in mind, that every reuse is not only a benefit concerning having less code to write, but it also increases the maintainability. One fixed bug for all platforms is easier than debugging several different platforms.
Can it do everything a normal (iOS / Android / Windows Phone / …) app can do?
Yes, indeed. React Native uses a bridge which you can easily extend to execute its native code. Doing so is easy, even for UI components as you may see here (Native Modules) and here (UI Components). There are also quite a lot of libraries which use this approach; you may want to check them out:
Can’t we use NativeScript, Xamarin, … ?
Yes, you can, both are options that share the capability to execute native code with React Native. I have personally never developed anything with one of these technologies, so I can not reason about them, but I would like to emphasise one strength of React Native those tools don’t provide; It is React. React has some great advantages I won’t explain in detail, please see this blog post (It’s a bit older but still great). Additionally, one may use the whole React ecosystem (Redux, Relay, …) with React Native, which simplifies cross-platform development a lot.
Other points for React Native
As this is the first part of a series, which covers pitching React Native it is clear that not all benefits are covered now. But here are some links to the next parts, which may also be interesting to convince developers.
- We already have an existing app, so there is no need for React Native (Coming Soon)
- React Native has awesomely fast feedback loops (Coming Soon)
- React Native makes working with Designers so much easier (Coming Soon)
EDIT:
If this was interesting to you, you might want to check out these slides by Brent Vatne.
Want to hear more from me? Feel free to subscribe to my newsletter; I send out news roughly once a month.
