In my last post, I looked at what I feel are the many positives of using React Native (RN).
I recommend you read that article before this one – there’s a lot to like about RN, so don’t read this post in isolation. Nevertheless – going with RN does have its downsides, in my opinion. Here they are:
2) Dependency management
The most popular dependency management tool for RN is npm, and I found it was regularly a source of issues. It’s nothing too onerous, just not as straightforward as I’d have liked, and I think better alternatives are available (Yarn, for one).
3) RN is dependencies
4) OS Modules vary wildly in quality
Most of the time you won’t be writing your own modules – you’ll be using the packaged ones or OS variants. It should go without saying, but a thorough code/project review is essential before integrating any third party modules; while some are great, some will be more trouble than they are worth.
You’d expect a lack of documentation when using a fast moving, bleeding-edge product, nevertheless it’s something to consider. The documentation for RN could definitely be better, and the current situation can make it harder to navigate and become productive.
6) You’ll miss the compiler
This is essentially the flipside to the flow/eslint positive I mentioned in the first part of this article. If you or your team have not worked in a dynamic scripting language as your main programming language before, do not underestimate this aspect. ‘Undefined is not a function’ is the cliché, but it’s an experience you don’t often have in a compiled language.
7) Little to no Swift
For the iOS side, Facebook took the decision when it started RN to use Obj-C (a good decision at the time, given the new and changing nature of Swift and the fast compile times of Obj-C). But unless Swift adds support to make precompiled macros (which some may argue is a corruption of Swift), the transition may never occur.
8) RN Internals
RN is developed largely in the open, on GitHub. While this is great, the Obj-C code does have a feeling of ‘Death-By-A-Thousand-Facebook-Engineers’. The style seems odd to native developers (the two-space indentation, for starters) and for other more complex OS reasons, it’s intimidating and inaccessible.
On the other hand, running on an RN fork to get over a bleeding edge issue is possible, and I’ve seen it happen – and that’s a flexibility that native cannot generally offer.
9) Inconsistency between platforms
Some things on Android are better or worse than iOS, and vice versa. Android’s text implementation is not as slick as iOS, for example. So you occasionally do still have to duplicate effort for both platforms. Still, this will be the case for most cross platform tools.
Navigation within an app is always tricky. How do you choose the best way to change context for the user? Well, there are established ways to do it in RN, and this was by far the hardest aspect I encountered. Representing navigation in ‘reducers’ was painful for all involved.
As I said at the outset, don’t read this post in isolation; the many positive aspects of RN definitely make it worthy of your consideration. But these downsides are crucial to consider, too.
In the final part of this series, bearing all these positives and negatives in mind,
I’ll be looking at the questions you and your team should be asking before deciding whether to use RN.