
Why I'm Not a React Native Developer - objectiveariel
https://arielelkin.github.io/articles/why-im-not-a-react-native-developer
======
jamon51
Complaining about longevity of React Native and then recommending two
proprietary, non-open-source competitors is, frankly, absurd. If Facebook ever
abandons React Native we have all of the code and can continue to support it
ourselves. If Microsoft or Appcelerator ever shut down their platforms for any
reason, we're SOL.

While there are some valid concerns with using React Native, the productivity
gain and community make it a more than worthwhile trade off.

~~~
jamon51
I should also mention that we've found React Native to be far more productive
to use than Appcelerator or Xamarin. Not sure what the author used to
determine those charts near the bottom.

------
brentvatne
\- No clear roadmap

Indeed this would be nice to have!

\- No guarantees from Facebook about longevity

As more products within Facebook (eg: Instagram) and companies outside of
Facebook are depending on this (Airbnb, Netflix, Alibaba, Microsoft, Baidu,
Uber), there is a bigger community of folks who share the burden of keeping it
going.

\- Legal concerns

This is the same license as React. Given the breadth of companies depending on
React (all of those mentioned above, plus thousands more), I suspect that
their legal departments considered it to be acceptable. If you don't, that's
certainly fine!

\- JavaScript problems

JavaScript does have plenty of problems, but it's also what enables a lot of
the nice things about React Native (x-platform, ota updates, resource sharing
-- as the author identified).

\- Alternate frameworks: Xamarin, Appcelerator

I'd like to see the author write a similar assessment of these tools! It's
worth noting that the author seemed to be unaware of the existence of React
Native for UWP, maybe that would alter his assessment.

------
SimonSelg
Great article. On a side node, however: please don't write code like this:

    
    
      var weAreConnected = Math.floor(Math.random() * 10) > 5
      if (weAreConnected === true) {
        this.setState({
          isConnected: true
        })
      } 
      else {
        this.setState({
          isConnected: false
        })
      }
    

Instead, simplify the logic

    
    
      var weAreConnected = Math.floor(Math.random() * 10) > 5
      this.setState({
        isConnected: weAreConnected
      })
    

The random choice is also overy complicate (and on a side node, the value is
more likely to be false then true due incorrect comparision operator usage)

    
    
      var weAreConnected = Math.random() < 0.5
      this.setState({
        isConnected: weAreConnected
      })
    

If we use ES6, we can use the shorthand notation to simplify the code even
more

    
    
      const isConnected = Math.random() < 0.5
      this.setState({
        isConnected
      })

~~~
christiangenco
I'm so glad you noticed this - it was bugging me.

I've noticed a pattern in "X vs. Y" articles where the examples of the
technology the author doesn't favor are unnecessarily complex.

------
tyler-morrison
Wonderful article! As a JavaScript developer, this is the first time I have
seen a well-written critique of the language shortfalls. Usually these
counter-arguments can't help but feel like flame wars.

That said, I think every JS feels these pressures internally. In 2015, some
were even brave enough to give it a name — "JavaScript Fatigue". I personally
work with TypeScript. But each time you kickoff a new project these days, the
task of getting past all the boilerplate work seems to be increasingly
difficult.

------
rubyhacker88
While I can't argue the shortcomings of js, it's hard to not see most of the
argument as a strong stance of statically typed languages that get compiled
against those of dynamically typed languages that evaluate at run time. Both
types of languages have their time and place and I wonder if bringing that
discussion dilutes the discussion to avoid react native.

On the point of community versus big company support I can't help but observe
what appears to be anti open source sentiment conveyed as fact. While many of
us have seen fads come and go we have to admit the wild success and stability
of many open source libraries without formal agreements to maintain them.
Everything from Rails, to Django, to jQuery, and Linux distros. There is a
caveat here that JS libs do seem to die out faster and have questionable
quality but again plenty are also great.

I think the choice of React Native really boils down to understanding the
platform and source. If you understand how React Native leverages the toolkits
and interacts with the system I think you have the tools you need to make a
good decision.

For me I prefer native development where I can easily control and limit
dependencies. If I want to hit all devices or most I'll build a great
responsive web app. At the end React Native is today NOT a production level
solution that will cover android and iPhone devices, android is a separate
toolkit.

My rambling is done I suppose. If anything can be gleaned from this it is to
understand the risks and be mindful of the costs of adopting a new framework
and dev environment. If you are careful, intentional, and lean on smart
teammates for help you will be just fine.

------
ctvo
Opens with how other articles on React Native haven't been comprehensive, goes
on to fill most of it about JS short comings like we haven't been aware for a
decade.

And the recommendation at the end for Flutter, which shares all attributes of
RN (open source, free, cross platform, from a large tech company, but one
known for killing projects), was strange. It made the argument essentially I
want RN but not a dynamically typed language.

------
romulobr
Very convincing. Now I really want to use react native!Thanks. The author
points to lots of benefits and advantages in using react native, then shows
some legal stuff you might or might not worry about (with a tinfoil hat
example), then complains A LOT about javascript, making it very clear he
doesn't really get it and can't understand how its ecosystem currently works.

------
jsdev2
Hmmm I'm not writing articles about Elixir downsides, form the simple reason -
I don't know this language well. Your article was written to show downsides of
JavaScript, but example codes was written terrible. A lot of mistakes, weird
examples and no basic knowledge how JavaScript is interpreted at runtime

~~~
jamesmp98
The mere fact that you suggested Elixir has downsides will make the functional
elitists go crazy.

------
hokkos
There is no need to complain about Javascript once again, we know it all, the
Flow criticism about the percentage of .js files is ridiculous, what is the
percentage of Xamarin C# in all C# files ? The whole number is more important
that the ratio. Also the portability of Xamarin is overestimated, you choose
to use native non portable components or non native one but portable. The
longevity of Xamarin is also overestimated, this is closed source software
where React Native is open. This is not a good article overall.

------
jamesmp98
I simply cannot bring myself to use Appcelerator or Flutter. Isn't
Appcelerator expensive (like Xamarin used to be)? Xamarin is ok, but keep in
mind unless you use Forms, you are still using the iOS and Android SDK's so
you still need to be proficient in both, so it is not as xplat as you think.
Flutter would be ok, but I don't trust Google with Dart and it looks extremely
underpowered with no community.

------
vim-guru
You don't have to write JavaScript code to use React Native:
[https://github.com/drapanjanas/re-natal](https://github.com/drapanjanas/re-
natal)

~~~
jamesmp98
I've seen Ruby and F# used too.

------
flukus
I tried react a native a couple of weeks ago but due to a change in android
versions the hello world tutorial wouldn't work. I got the distinct impression
that it doesn't simplify android development, just adds it's own complexity on
top.

The whole native widgets thing gave reminds me of GWT/AWT too, we're going
around in circles.

------
nomad101
Really ? No opinions on this very well written article on HN. Surprised!

