State of React Native

This blog post is not 100% directed towards React Native but on the
entire stack of React Native. I recently started working on a project
which explores React Native. I followed a wonderful
tutorial which, at the
time, was only a couple months old. This should not seem like a big
deal but in the world of Node.js it is and
that is exactly what I want to touch on today.

My Take on Native Development

I have been developing both iOS and Android native mobile applications
for a couple years now and the most frustrating aspect is the “That’s
the way you do it” mentality *cough*Apple*cough*. Apple provides a
lot of snippets and example applications that illustrate how one could
build an application. However, the issues that they do not emphasize are
testability and a concise project structure which both lead to good
architecture. The promotion of good practices such as
Separation of Concerns
and
Inversion of Control
are not conveyed to the audience. Perhaps these techniques are not the
responsibility of Apple and Google but that is not what we are here to
talk about; we’ll save that for another day. For anyone that has done
any iOS development you have already come across the issues of Massive
View Controllers. Not only are good practices not promoted but actually
implementing a good architecture is difficult especially if your
application relies on Core Data; it is an up hill battle. There are many
different attempts at clean architecture but none are revered as the
standard. In short, while writing native applications it seems overly
exhausting to be a good developer.

My Take on React Native

React Native is all the buzz right now. Is it a fad or is it here to
take over the majority of traditional native development? We shall see.
Regardless of the answer, I currently get calls from recruiters all the
time now because of my mobile development experience. Later to realize
the potential client really wants a React Native developer. So,
reluctantly I jumped into React Native development. Now, keep in mind I
despise JavaScript, so I went into this project with a chip on my
shoulder. All and All, I must say that I was pleasantly surprised at how
much I liked development with React Native; it was very enjoyable to write
code. Separation of concerns was trivial. I used
Redux, which was also fantastic! However, there
are definitely some frustrations and concerns about using React Native.

Frustrations

Dependency Hell

For anyone new to the Node.js ecosystem, simply put, it is a bunch of
small packages plugged together to create a larger package. With that
comes a lot of decisions to make. Most of the decisions have already
been made for you because of the dependencies of your dependencies but
you still need to make a choice on what first order dependencies you
will be using. If you are like me, you will probably want to vet out
your dependencies before using them. So, let’s use a real example. Let’s
say we want to use a package for forms in our new React Redux
application. Go to
npm
and search react redux forms, go ahead I’ll wait. How many results did
you get? When I did it at the time of writing this post it was 43
packages. Where do we even start with vetting out which package to use.
As you could imagine this happens a lot and it can be overwhelming.
There are several factors I consider before pulling in a dependency one
of which is getting a general feel for the support for the dependency
itself (this is not the only thing I consider but for the sake of
brevity we will simply consider support).

Editors

Another frustration I had to overcome was choosing and setting up an
editor. First question, what editor do I use? Well there is the well
known Sublime Text, the new Github
built Atom, don’t forget the Facebook React plugin
Nuclide for Atom, and then there is
Visual Studio Code. I naturally went
to Atom with the Nuclide plugin; seems like the best tool for the job.
Well, after about an hour I found myself frustrated with the
intellisense, maybe I didn’t have it setup right? So, I decided to give
VS Code a try and to my surprise it had better intellisense support for
React than Nuclide. With the exception of a couple nuances VS Code has
worked surprisingly well.

All these editors have one thing in common, they all have a large set of
plugins that can be leveraged. These plugins are all apart of the
Node.js ecosystem, which is managed by using npm. Surprise! We are going
to have the same type of issues we already covered with dependency hell
and all the fun that comes with it. But one other thing that seems to
fail me is understanding how to properly configure all the plugins that
are needed to get the editor working the way I want. I still don’t have
a “perfect” setup.

Concerns

Early Adoption

React Native is still very young and the npm packages are even younger
and there are a lot of the same packages trying to solve the same
problems. As mentioned before the amount of packages can be
overwhelming, to say the least. Furthermore, one of the issues that I
encountered when going through a 5 month old tutorial is the packages
used in the tutorial were all out of date. One of the packages I was
trying to use from the tutorial was not updated to work with the latest
version of React Native. Good thing there are 100 other packages just
like it ;)

Native Operating System Update

Anyone that is experienced in mobile application development knows the
release cycles for Android and iOS Operating System releases. For anyone
new to the game here is an overview. Android and iOS operating systems
are announced about the same time every year, May - June time-frame.
Because of Android’s
fragmentation problem
this issue is not so pressing unless you are always on the heels of
supporting the latest and greatest features. iOS on the other hand is
much more concerning. One of the nice things about developing for Apple
is the extremely high adoption rate of the newest OS. This is a double
edge sword though. Because the adoption rate is so high
(check out how fast iOS 10 was adopted)
you must also be on top of making sure your application can support the
latest OS, which is only about 6 months from initial announcement to 85%
adoption in production. So the big concern is, at what pace will a
package be able to keep up with the ever changing React Native
ecosystem? This means, at very least, ever year React Native will need
to be updated, which could take some time. Let’s say you are using
package X in your application. Package X depends on React Native
releasing its updates so that package X can be updated. Once the
developers of package X finally release their updates you can start
implementing it in your application, and that assumes package X is still
supported. Assume happy path and this still could significantly reduce
your OS preparation window.

Longevity

With any dependency, longevity is a concern that is always on my mind
and this is typically why I do not opt for anything but pure native
development. With companies such as Facebook, AirBNB, and Artsy backing
the survival of React Native there can be some security that it isn’t
going anywhere anytime soon. But that is a big scary assumption, don’t
forget about Parse.
Nothing is guaranteed!

React Native License [Updated: 9-27-2017]

This is no longer an issue with Facebook addressing everyone’s
concerns and switching to an MIT license. More Info

I hesitated even bringing up the
React License because
there are so many other places to read the on going debate but I need to
touch on one small topic.

No matter the true intention of the license verbiage one thing is for
sure, you better run this by your clients or your own legal department
before using React Native. Look, the last thing you would ever want is
to be months into development when all of a sudden Seth from the legal
department storms in screaming “Please tell me we aren’t using React
Native!” I am not saying there is anything scary about what Facebook has
in its fine print but the legal department where you are working might
not like it. It is just good to get it cleared first.

Conclusion

This post may seem like I am trying to sway people from using React
Native but I assure you that I am not. There are a lot of benefits I
found while working with React Native, the most important one being how
enjoyable and easy it was to write good clean code. React Native is not
a golden hammer but yet another tool
to keep in our shed. It does not solve every problem, nor should it, but
if you plan on developing an API driven application I would put some
serious thoughts into using React Native as your tool of choice.