
How to Beat Your Competitors Using a React Native Technology - amazonkaiv
https://blog.aurity.co/how-to-beat-your-competitors-using-a-react-native-technology-7c8f658bb24f
======
everdev
Are there any downsides to RN? The old criticisms used to be: license type,
difficulty in publishing to App Store, not full featured.

Any of those still fair or have things evolved to where the author claims it
saved 40% on time and budget vs native coding?

~~~
tspike
Having worked on a large native codebase with RN features integrated for a
couple of years now, there are a lot of downsides for our particular use case.
I am aware that some of these are organizational rather than strictly
technical issues, but I think there are very few organizations that would not
face similar hurdles:

\- Instead of 2 platforms to support, we now have 3

\- Debugging issues that cross Native <> Javascript is a nightmare. Only a few
developers are skilled enough to do it well. Even then, the overhead involved
in determining with certainty that the issue is on the native or the JS side
and engaging the relevant developers negates most savings.

\- Code that's shared across teams is difficult to share with the JS teams and
vice versa. Consistency between native and RN is poor.

\- Adding JS to the codebase exploded our dependency graph. One feature team
introduced over 700 (!) dependencies via npm, which brings me to:

\- Enforcing code/quality standards is difficult. Same app, completely
different tech stacks

\- Educating JS developers about ensuring compatibility with native
dependencies is an ongoing expense

\- Massive new attack surface area is now exposed via the increased
dependencies (see [https://hackernoon.com/im-harvesting-credit-card-numbers-
and...](https://hackernoon.com/im-harvesting-credit-card-numbers-and-
passwords-from-your-site-here-s-how-9a8cb347c5b5))

I can go on. I think it's actually a super cool and ambitious technology. I
had the opportunity to hack on some of the internals as part of an exploration
to see how easy it'd be to share our native UI components with it, and that
was pretty darn fun. It's just very, very poorly suited for integration with
an existing large codebase, and decidedly not a miracle solution.

If I were bootstrapping a startup with no existing codebase and needed to
target web, Android and iOS it'd be a no-brainer to use RN, but that's a quite
different scenario.

~~~
sameers
Is there some subset of native capabilities that one can still attack with an
RN codebase and not have to deal with the native <> JS issues you ran into?
Say, my app "only" needed to access contacts and images (no GPS; no bluetooth;
not take pictures; not worry about accelerometer; etc.) - in your experience,
does that put RN back in the picture (somewhat)?

~~~
tspike
You _can_ do just about everything a native app can do with RN. If you have a
very small, capable team that's all on the same page, it's a good choice. For
large existing codebases in large organizations, it's a very poor choice.

~~~
kanalas
Having worked alone with react-native for about 3 months now and building our
production application, I'll go further and state that for certain kinds of
tasks React Native is definitely the way to go, but if the requirements seek
heavy background work or involving multiple threads native code seems to be
way to go. I'd love to hear your thoughts on Flutter. Cross compiling to
native seems to give us the gains with respect to almost close to native
performance too.

