What is React Native
React Native is a native version of the popular web library of the same name and its main purpose is to bring the power of React to native development. React Native components are pure, side-effect-free functions that return what the views look like at any point in time. For this reason it is easier to write state-dependent views,as you don’t have to care about updating the view when the state changes since the framework does this for you. The UI is rendered using actual native views,so the final user experience is not as bad as other solutions that simply render a web component inside a Web View
Costs of React Native
PROJECT SET UP
The documentation about setting up the testing environment is very poor, and mostly outdated. Consequently, we spent 4 days until we were able to run all of our tests successfully. While it’s true that we didn’t have any prior experience on running JavaScript tests, we found the amount of effort to set up the test environment outrageous. There were other setup quirks as well, mainly caused by incompatibility issues with different versions of the framework.
IDE
The recommended IDE is Atom, with a plugin on top of it, Nuclide, which adds support for React Native development and for its recommended static analysis tool Flow. While it might be a good editor in general for JavaScript development, we found it to be far behind compared to IDEs we are used to, like Xcode and Android Studio. For instance, there is no support for even the most basic refactors, this could potentially slow down the development speed.
SPEED
As native developers we found the learning curve of React Native pretty high, as it may take up to a month until one could start feeling comfortable developing with this framework. For someone who is already familiar with JavaScript development, Redux, flow layouts and maybe even React, it is much faster to get up to speed with React Native.
NATIVE CODING
There are certain features that cannot be implemented solely in JavaScript, native code is needed for:
- push notifications
- deep linking
- native UI components that need to be exposed to React.
Overall approximately 80% of the code is shared between iOS and Android and written in JavaScript.
HOT RELOADING
Hot Reloading is similar in concept to Instant Run on Android. Every time a source file was saved, the changes were deployed immediately on the device where the app was running, thus greatly expediting the feedback loop. Although it works better than Instant Run, it still breaks from time to time, requiring a restart of the app.
3RD PARTY LIBRARIES
We cannot deny the fact that many times we have to resolve the same problems as others did before us, and that’s why we decide to make use of third party libraries, so we don’t have to reinvent the wheel. Whereas there are plenty of libraries to chose from on iOS and Android, we cannot say the same about React Native. There are definitely a considerable number of libraries, but as we experienced, some of them are not always working as expected.
RELEASE CYCLES
One more thing worth mentioning is that React Native has a two week release cycle.While it is good that they bring more features and push the framework towards maturity, often they bring breaking changes as well, maybe in a “move fast and break things” fashion specific to Facebook. These changes sometimes where a burden to overcome, as we had peoples pending a lot of time fixing things when upgrading the framework. But we can’t deny that this isn’t expected, as the framework has yet to reach a stable status, still being under heavy development.
COST SAVING – THE NUMBERS
With these pros and cons, the state of the tools, the lite documentation and uncertainty of libraries as it is in the present, we feel that by using React Native you can actually save some time compared to traditional native development. In particular, according to the developers we have interviewed, on real projects one could save around 30% of development time. Of course this is just a high level estimate and depends on multiple factors, the most relevant is to have person with web-development knowledge in your team, as discussed previously on this article.
Why Choose React Native
At this point, you might think that React Native is another “write once, run anywhere” framework, like Titanium or PhoneGap, but you would be wrong. As Facebook very clearly states on their blog post, they acknowledge the differences between platforms, so instead, their goal is to bring the paradigms of React, which is very successful on the web, to native,while having the same set of engineers working on whatever platform they choose. They call this approach “learn once, write everywhere”.
How React Native actually works is by embedding the JavaScript files in the app, and running them locally. But also, one could have these files remotely on a server fetching their latest version when the app has connectivity. This would allow updating an application very rapidly, without having to go through the app store’s review process. There are also third party services that offer such solutions, and using them potentially could mean that for smaller applications that don’t have a lot of data to display (e.g.festival apps), a back end isn’t needed anymore.
Most of the coding is based on JavaScript and the paradigms in React. Thus, it makes more sense that a typical team working on a React Native application is composed mostly of JavaScript engineers, because ideally those will be already familiar with the tools and paradigms used by this framework: React, EcmaScript, Redux and Flex layout.
Limitations
DOCUMENTATION
Starting to work with a new platform like React Native, one of the first things we did was to explore the available documentation, both official and from the community. We found that, while Facebook is putting effort in keeping it up to date, a good amount of the components are not well documented for the current release of React Native. This is even more evident if we consider community-created articles, given that these are often obsolete after a few releases of React Native.
CORE REACT NATIVE LIBRARY
When the documentation wasn’t satisfying enough we tried looking up things in the React Native source code, however we found ourselves disappointed by the poor quality of code base. Probably in a rush to push more functionality to the framework, they also sometimes overlook how clean the code is.
Speaking about the core React Native library, we found many of the main components being still in a Work-In-Progress status. The official documentation regarding how to implement some key features (like navigation)changed the suggested component in different releases of React Native. The migration from one to another of these components is not a straightforward task and it requires some not-negligible work.
THIRD-PARTY COMPONENTS
Of course it is possible to use third-party components, but the selection is not comparable with the number of community-generated libraries that we can find for iOS or Android. A big problem with these components is also the fact that the compatibility and support is not guaranteed with future React Native releases.
NATIVE SDKS UPDATE
When the iOS or Android SDKs are updated, it takes some time for React Native to integrate these newly introduced APIs into their core library. The React Native team is pretty fast to update in order to allow developers to use new APIs, but the priority is given by the amount of requests that every API gets. It can happen then, that some new features will be included in the next React Native release, while some others are not going to be included at all.
source: https://blog.novoda.com/is-it-the-end-of-native-development/