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:

1) Javascript is a shaky tower

I won’t get into Javascript’s problems here, the arguments are already out there. Arguably it can get the job done and that’s all that matters. And magical things can be done on shaky towers! Nevertheless – RN relies on Javascript. To me, that’s not a plus point.

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

Related to the above, RN lives in the Javascript ecosystem. Being productive requires hundreds, almost thousands of different dependencies. So be ready to get stuck in if any go wrong.

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.

5) Documentation

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.

To paraphrase one sentiment I heard while working with RN: “In Javascript, you just don’t make mistakes”. I personally found this preposterous, life is perpetual mistake making. A compiler is your crutch and more besides, and not having one is a negative in my book.

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.

10) Navigation

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.