There are tons of hyped-up claims surrounding React Native that are worth addressing.
The reasons why companies run for React Native are usually,
Let’s address the first claim. Yes, you can indeed use Javascript for building your mobile app. But it is just a dressing on top. Underneath, you are using various React Native libraries that contain Java code to integrate with the Android framework. That leads to a few problems.
One is that you will see crashes/bugs in the React Native library that you imported and you will have to go in and fix it. So, the Java code is never invisible. Secondly, Android has tons of helper libraries like AppCompat, AndroidX, Arch, etc. As soon as you introduce a layer of indirection in terms of accessing them, you are dependent on the author of those libraries to fix it.
Another problem that happens is that cross-language error handling is hard. If the underlying system throws a checked exception, how is that supposed to be propagated back to Javascript which does not have a concept of checked exceptions? What about unchecked exceptions? What if they aren’t even documented? This can lead to the program entering unexpected states and appearing unresponsive.
The third major problem that happens is this magical belief that because you are using Javascript, it is the same platform. Javascript was meant for adding dynamic components to HTML pages. Not to run background tasks on long-running mobile apps. Many websites cannot handle intermittent connectivity drops while loading. And that’s acceptable since the users are used to refreshing a web page. Mobile apps are expected to work differently. Even more so, on both platforms, Android and iOS, one can do limited background work, albeit with a different set of restrictions. Javascript isn’t even multi-threaded and that leads to performance issues. Over time, as you start building more and more features, you realize that you still have to learn the underlying platform alongside an extra Javascript library. For example, say you want to build an Android Auto integration in your app, you will have to understand what Auto APIs’ capabilities are apart from finding a React Native library to integrate with.
You can indeed use a single codebase to write Android and iOS. And probably even backend code as well, just have different code paths and trigger different parts of the code. But that’s not code sharing. It is more akin to doing a sack race where a strong amount of coordination is required. That’s what Airbnb experienced. While a single codebase means that you can build new features and fix bugs in a single place, it also means that one would have to test on both Android and iOS simultaneously. And what about Android fragmentation? or even iOS fragmentation? What if the UI library that you used has a bug on a certain version of a platform? Consider all the bugs Android and iOS frameworks have. Now, add all the bugs that React Native has. Your surface area of hitting a bug has only gone up. That’s one of the critiques Steve Jobs had of Flash-based apps.
Let’s look at the final claim that Facebook uses it. Only a small fraction of the Facebook app and that too non-crucial features are written in React Native. Other companies like Udacity and Airbnb tried and gave up on React Native. Dropbox tried a common C++ layer for Android and iOS gave up as well. Discord faced tons of performance and battery drain issues as well. If all these well-funded companies had a tough time making React Native work, ask why would it succeed in your case.
One thing that many don’t realize is that React Native packages come from NPM. And that’s a security mess. Of course, it matters less if you are building a music player but if you are building finance or a cryptocurrency app, it is a matter of time before you will be targeted. And this matters more to React Native apps than native apps. The native apps might depend on some external packages as well. But the React Native app will depend on third-party packages for even trivial functionality such as writing to disk. And npm packages themselves suffer from dependency bloat.
As of Jan 2021, the latest version of React Native is 0.63. It is less than 1.0 to indicate that the APIs have not stabilized even after 6 years. So, who pays if the API is unstable? And what if you want to use two libraries that were built against two incompatible versions of React Native? Or one against AndroidX and another against deprecated Android’s AppCompat?
So, what are good cases to use React Native? When your app does not use the contact book, system notifications, compass, or any other system-specific feature. In that case, also, consider building a good quality web app instead and let users install it as PWA.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。