
Why I'm not a React Native developer - RyanShook
https://arielelkin.github.io/articles/why-im-not-a-react-native-developer.html
======
whistlerbrk
This article raises so much unfounded FUD it's hard to believe the author is
serious.

1\. Uncertain Roadmap - Does anyone seriously doubt FB's commitment to RN?
When they themselves dogfood it? Or is it more likely they are just too busy
making progress (since as the author points out they release every 1-2 weeks)
to release a multiyear ROADMAP?

2\. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has
the team of lawyers to undergo that? This is for 99.999% of people not a
legitimate concern. This is an RMS concern.

3\. Javascript - New versions of Javascript address the vast majority of this.
Type errors? Use well supported Typescript or Flow

4\. Dependencies - This is a result of the Javascript communities overly
enthusiastic packaging efforts. This is not an apples to apples comparison,
but of all the cons mentioned, sure this is legit.

5\. Alternatives - ...and Windows Phone? Seriously? I was rooting like hell
for MSFT, but this is just not a thing. I'd rather cover 99.6% of users twice
as fast than 99.999 of users painfully using Appcelerator

~~~
mtviewdave
> Does anyone seriously doubt FB's commitment to RN? When they themselves
> dogfood it?

After the shutdown of Parse, I don't see how anyone could avoid having doubt
about Facebook's commitment to React Native, or to anything else outside of
their core business.

~~~
oakesm9
Parse was never used internally at Facebook I don't think. React Native is
used for major parts of the main app and in parts of Instagram. I don't think
it's an apples to apples comparison.

~~~
LeoNatan25
Where's your proof?

The FB app uses RN for very esoteric and small portions of the flows. It has
230MB (at least) of compiled binary.

Instagram also uses it minimally, mainly to replace what used to be webviews.

Those are not "major parts".

~~~
dymk
It's used in Marketplace.

[https://facebook.github.io/react-
native/blog/2017/08/07/reac...](https://facebook.github.io/react-
native/blog/2017/08/07/react-native-performance-in-marketplace.html)

------
Rockslide
OK, this isn't really important for the quintessence of the article. But I'm
surprised again and again how many developers write code like

    
    
      if (weAreConnected === true) {
          this.setState({
            isConnected: true
          })
        }
        else {
          this.setState({
            isConnected: false
          })
        }
      }
    

instead of

    
    
      this.setState({
        isConnected: weAreConnected
      })

~~~
vmarsy
What if `weAreConnected` is `null` or `undefined`?

WalterSear's solution solves the issue since both `null` and `undefined` would
become `false`:

    
    
        this.setState({
            isConnected: Boolean(weAreConnected)
        })
    
    

but in your case you could set `isConnected` to `null` or `undefined`

so if later in code someone makes the mistake of writing:

    
    
        if (this.state.isConnected === false) { /* do stuff */ }
    

they could have a bad surprise.

~~~
debaserab2
this.setState({ isConnected: !!weAreConnected })

~~~
DeonPenny
Ding ding ding right answer. This is the way most senior javascript devs would
right it.

~~~
corn13read
They'd right it if they were fixing it or write it if they were writing it ;)

------
savanaly
I'm really glad to have read this article as it actually solidifies my comfort
with using React Native since it seems like a well thought out list of reasons
not to use React Native, and now I know that none of them really matter that
much to me.

The three main disadvantages of React native brought up are:

\- lack of commitment from Facebook about maintaining it for a long time. This
one is the most bothering to me but it's not a dealbreaker.

\- doesn't like Javascript and its related ecosystem. This doesn't bother me
in the slightest, I love modern JS.

\- the whole all your patents are belong to us thing that comes up every so
often. I'm not a startup founder or a lawyer so I will leave such concerns to
them. If my employer wants to let me develop in React, all the better for me.

~~~
kkleindev
I'm curious, what do you love about JavaScript?

~~~
briandear
Probably that he knows it and doesn’t know Swift.

~~~
LeoNatan25
What kind of a reason is this? "Ignorance is a bliss."

~~~
blunte
The point was probably that someone with a good knowledge of one language and
little or know knowledge of another favors the one they already know.

There are plenty of people who are quite happy with what they have, and they
see no reason to change. Then there are people (thankfully) who are never
satisfied and who keep progress rolling.

~~~
LeoNatan25
> Then there are people (thankfully) who are never satisfied and who keep
> progress rolling.

 _“Here 's to the crazy ones. The misfits. The rebels. The troublemakers.”_

------
Jeaye
So, you'd rather use Xamarin than React Native, in short. Xamarin has
excellent tooling and arguably works with saner languages (with better type
systems), but _it doesn 't work on GNU/Linux_. We're using RN right now, since
it allows us to use ClojureScript, which means we can share code between our
Clojure sever and our client. This means we're limited to the JS environment
though, which means no good access to multi-threading and a really wonky
target language. Performance implications aside.

If Xamarin worked on GNU/Linux, we likely would've built our app using it and
F#. Until it comes to the Linux world and stops doing things the MS way (open
sourcing is a good start), Xamarin is going to be missing out on a number of
developers.

~~~
LeoNatan25
There is Mono on Linux, and it works quite alright. Xamarin can be made to
work with Linux, it's jut not officially exposed in the UI by default.

~~~
Jeaye
Xamarin and Mono are not the same thing. Also, Xamarin Studio may work through
WINE or something similar, but it doesn't have any native GNU/Linux builds.

------
loftyal
I think people should be paying more attention to the core concept of React
Native, which is having a view layer that is completely native and a bridge
that connects to a javascript engine. People bitch about electron which is
essentially a browser in an app window (React Native is NOT that), the
concepts of React Native solves a lot of the performance problems of Electron,
which I think the electron team should seriously consider implementing.

~~~
eadmund
> I think people should be paying more attention to the core concept of React
> Native, which is having a view layer that is completely native and a bridge
> that connects to a javascript engine.

That is indeed pretty awesome, but wouldn't it be even better were it a better
language than JavaScript being bridged to? I'm thinking Lisp, or Python, or
TCL, or pretty much anything other than INTERCAL or JavaScript.

~~~
oceanswave
Out of the languages you mention, I'd still pick JavaScript + typescript

------
ups101
TL;DR: "react native sucks because javascript". So much else I wanted to know
from an experienced iOS dev, like:

\- How is perf in a large app with lots of network IO? \- How does animation/
transition fit with reacts render loop and how does it perform, especially
during network IO? \- How much is lost from not being able to do
multithreading? \- How hard is it to achieve the last 20% fine tuning of feel
and perf? \- How much flux is the community driven deps typically causing? \-
Is memory management an issue? GC stutters, leaks? \- Do some UI parts simply
not scale well enough, requiring native code instead? e.g. infinite scrolling,
charts, complex transitions? \- How mature is the tool chain? Build time? \-
Frequency of breaking changes from core? from common deps? Cost of staying up
to date?

Developing in JS, with all the pros/cons of the JS language, is the very
premise of the react native deal. Most issues raised would apply just as well
to any web app.

------
azangru
The example with the Person class suggests that the author is unaware of
JavaScript getters:

    
    
      class Person {
    
        get isImmortal() {
          return false; // noone is immortal
        }
    
      }
    
      p = new Person();
    
      p.isImmortal
    
      // >>> false
    
      p.isImmortal = true;
    
      p.isImmortal
      // >>> false
    
    

I mean, even plain untyped JavaScript can do _that_!

~~~
objectiveariel
You're missing the point. The fact that the language still allows you to write
`p.isImmortal = true;` is the issue.

~~~
oceanswave
And my linter, or flow, typescript will pick that up in the same way the
compiler will. Just because tooling these days catches these things in 'type
safe' languages doesn't mean it's not a pointer to a chunk of memory that's
defined at runtime beneath it all.

------
roywiggins
NaN !== NaN is not a JavaScript thing, it's a IEEE754 standard thing.

The bulk of the gripes about JavaScript are entirely fair, but I'd think that
most people who use React Native would be aware of them already?

------
grandalf
This article is definitely FUD, there are a few irritating things about React
Native, but I think it's still far preferable to native development for most
apps.

I'll list the annoyances:

\- npm is a mess, and many libraries in the ecosystem handle sub-dependencies
improperly. Facebook has contributed to yarn but has not established a very
clear contract for what a properly organized package should be. Thus it is not
possible to easily determine which package or sub-package, or sub-sub package
(etc) is misbehaving. I estimate that this issue has eaten up easily 10% of
the productivity gains that React Native has offered. Facebook generally
ignores the github issues about this stuff, in spite of hundreds and hundreds
of users having these issues.

\- Updating to a newer version of React Native is cumbersome. There is a
utility called react-native-git-upgrade which often fails to reconcile changes
in the ios-specific configuration files. Much of this is due to problems with
XCode (not sure how anyone tolerates using that). Compared to simple makefiles
XCode's system that react-native interacts with is horribly brittle.

\- Important libraries are not embraced by Facebook. Things like camera
support are not included in React Native's scope, so third party libraries
exist, yet often lag because the developer can't make time to keep up with
pull request. Facebook should hire the top 15% of community contributors to
maintain those projects in-house. Right now probably 30-50% of community
libraries are not compatible with the latest stable React-Native. Facebook
should realize that library maintainers do not have enough time to properly
maintain these libraries and should offer more support and guidance, not to
help the maintainers as much as to help people trying to use open source
libraries from the community.

\- Some of the React Native code is pretty ugly. A few times I've had to debug
issues and some of it looks like it was written very rapidly and could use a
refactor for clarity and ease of debugging. Not the core algorithms stuff,
just the bundle management stuff.

But in spite of all this I'd still use React Native on a new project. Most
apps that aren't strongly architecture-driven could be written in a day or
two. It's pretty amazing.

------
PaulRobinson
Our legal team at work (an e-commerce player with 9-figure revenues that's
raised 8-figure rounds over the years), are currently looking at React's
PATENT clause.

There is a dependency tree here around whether you currently (or plan to in
the future) have any patents. If you don't and you never do, then how can
Facebook infringe it in a way whereby you'd want to sue?

And then there is the cost of suing. We seem to be reckoning it would cost
around $1m to start a serious action against FB, so what does the cost of
replacing React look like in that sort of scale? We've costed that, in broad
strokes.

So on paper, it all looks like we're fine, right?

But...

But...

Here's where they take pause:

    
    
      The license granted hereunder will terminate, automatically and without notice,
      if you (or any of your subsidiaries, corporate affiliates or agents) initiate
      directly or indirectly [...]
    

Subsidiaries? We don't have any of those.

"Corporate affiliates"? What does that mean? Oh, it's anybody who owns at
least one share in us, or we own one share in them.

Wait. What? We have business angels, founders, multiple VC firms and other
investors. Do any of _them_ have patents that Facebook might infringe on? What
about future investors or people who we might want to be acquired by? Could we
have an acquisition blocked because the potential buyer has a war chest of
patents they value?

And "agent" means external law firms too, right? So if any of the companies we
use for advice on an on-going basis get involved in any patent action, what
does that mean for us?

Suddenly it becomes this huge sprawling mess. Risk aversion is important when
you're dealing with a company that is already carrying a 9-figure valuation.

We're trying to find a way around it. As an engineer I brought it up with
Legal because I want clarity for colleagues and myself: we want a green flag.

Unfortunately, in doing that, we may have brought enough scrutiny to it that
they are going to tell us to stop using it.

If/when that happens we'll talk about it and share that information.

In the meantime, we continue to use it, but we're doing so with caution, and
we accept there may be a re-tooling cost.

~~~
oceanswave
Microsoft uses React on office/outlook.com and they're much bigger than you

~~~
PaulRobinson
1\. They have more money too, they can afford to take risks 2\. They probably
already have a patent agreement in place with FB not to sue each other 3\.
It's perfectly possible nobody in MS has had this actually cleared with their
legal team. You can't assume they have.

------
briandear
Is it not true that a cross platform system necessarily results in an
application that is the lowest common denominator in terms of devices? How
does React Native work with ARKit for example? How does React Native take full
advantage of the hardware if it has to be cross-platform compatible?

The Facebook iOS app is slow, bloated and occasionally glitchy. A company like
Facebook seriously doesn’t have the resources to make Android or iOS native
applications? Because React isn’t “native.”

~~~
crispinb
> How does React Native take full advantage of the hardware if it has to be
> cross-platform compatible?

It's easy enough to add a native module to address specific hardware -- so
easy in fact that you can usually find one already done (ARKit for example:
[https://www.npmjs.com/package/react-native-
arkit](https://www.npmjs.com/package/react-native-arkit)). As with all 3rd
party library use you have to do your due diligence of course.

The more of these you use, the less 'cross-platform' your code becomes. If
there's enough similarity in hardware between platforms, you might write (or
find) a react-native library offering a javascript/RN API that addresses
native apis under the hood. This is done with animation, for example.

> A company like Facebook seriously doesn’t have the resources to make Android
> or iOS native applications?

I'm can't imaging they don't have the resources, and know nothing about FB or
its motives. But if I was managing a large cross-platform app, I'd definitely
want the largest number of developers I possibly could have communicating via
a commonly understood codebase, rather than via meetings and specs.

------
jack_pp
A problem is the author doesn't seem to care that much about portability, how
can you even say that Swift is an alternative to RN?

Was curious about counter arguments and came upon this :
[https://medium.com/@reicheltp/dev-diary-4-why-i-left-
xamarin...](https://medium.com/@reicheltp/dev-diary-4-why-i-left-xamarin-
behind-35817ccd07b2)

A little old but I think I prefer RN's disadvantages over Xamarin's

~~~
mmargerum
[http://www.elementscompiler.com/elements/silver/](http://www.elementscompiler.com/elements/silver/)

------
iroq
>There is a const operator, which helps ensure primitives don’t get mutated.
But anything that’s not a primitive is as malleable as jell-o

Making so many errors in a sentence about basic language features, when a big
chunk of OP's article is argumenting that React Native is bad because
JavaScript is bad... Maybe it would be less bad if OP actually learned the
language?

~~~
savanaly
>Mutating a primitive

Makes me picture some language where you write "1 = 2" and from then on in
your code all 1's are 2's.

------
bkovacev
Could be a bit off-topic here and I hope that my tone is not extremely
negative, but why is there a constant "Why we/i/should are/am/should _insert
possible negation_ _insert a random action_ and why should you" trend in the
professional blogs (not saying this author does the why should you part)?
Titles are getting hideous and repetitive. I sincerely hope that this tone
could be changed to something more meaningful/technical/constructive rather
than listing things why you are or you are not doing something (while this
author definitely goes into detail).

I definitely endorse freedom of speech and thought, but unless one is a vetted
expert in the matter, one should avoid making these blog posts. I'm not the
best chef in the world and I do things a certain way, but I do not go around
the world telling people that they should do it my way.

~~~
ksrm
Technical blog titles considered harmful? :)

------
alex_escalante
I found funny to say Javascript moves slowly when a lot of people is using
async/await, generators, destructuring, etc… _everywhere_ right now. And then
it dismisses Flow and even Typescript right away, yeah sure…

And the conclusions seem to favor Phonegap, really? Xamarin might not be that
bad but doing really nice UI on both platforms require two separate projects
(or modules at least).

My bets are still on Javascript :)

~~~
LeoNatan25
Right, much better to have a terrible UI on both platforms using React Native.
A great bet.

If you insist, you can use Xamarin Forms and have an equally terrible UI on
both platform as RN.

~~~
madeofpalk
idk, maybe try not building a terrible UI?

------
worg
Title should have been —Why I dislike JS as a Programming Language instead of
swift—

~~~
blunte
Plus the patent worries - that to me was the other big takeaway.

------
dreta
Xamarin is given as an example of a better alternative why exactly? You
develop a single layout in React Native, while in Xamarin you just share the
C# code, so separate platforms need separate UI code (unless you want to rely
on their weak Xamarin.Forms API), and at that point you can just write common
code in C or C++ and not rely on any third party. It's hardly comparable.

~~~
LeoNatan25
You can use Xamarin forms if you insist on sharing the layout and have a
terrible lowest common denominator fisher-price UI.

------
Keyframe
I come from a bit old school, C world, so excuse the naive question. Is it
possible to build both a desktop (Linux/MacOS/Windows) and mobile (tablet and
phone, android and IOS) application from same codebase (with slightly
different codepaths for UI specifics) with React Native or something similar?
I see Xamarin is almost there, but no Linux.

I have a need for an app that is mostly word-processing oriented in nature
with some interactive graphing and drawing, some displaying, creating and
drawing on top of PDFs too. I'm looking for easiest path to create something
crossplatform AND performant (and possibly easy on the battery).

~~~
tspike
Why not just go with C++? You'd still need UI code specific to Android, iOS
and Qt, but you could keep your logic layer shared between all of them.

~~~
crispinb
As a freelance developer at the low end of the market (ie. where most apps and
developers live), I can assure you that the logic layer is usually so small
that the benefits of making only it cross-platform would be minimal. Most of
the code in most of my apps is UI code. RN saves me roughly 80% compared to
two entirely separate native codebases. A cross-platform business logic core
saves me perhaps 20%.

~~~
tspike
Sure, I agree for a greenfield social/mobile/local mobile app, RN makes a lot
of sense.

> both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android
> and IOS) application from same codebase... word-processing oriented in
> nature with some interactive graphing and drawing, some displaying, creating
> and drawing on top of PDFs

... definitely doesn't fit that description. At that point, your choices are
JS with RN, React and Electron or C++. For custom graphics rendering and
editing, JS would be a very odd choice.

~~~
Keyframe
C, that is more C++ kind of is my choice (QT namely). I was wondering if there
is a faster approach with JS, since I don't care about what I work with in
this case, as long as it doesn't take me much time to do it. Xamarin seemed
like a good direction, but no linux yet. Electron, while heavy, seemed like
almost a perfect choice - but no mobile.

------
vbezhenar
Honestly the only big plus for React Native is that it allows to make both iOS
and Android apps at the same time. This is huge. I wrote one app and I'm
writing second one and I can't say that it's something particularly better
than Objective C, for example. May be for very big apps React would win, but
for small and moderate apps I feel that React doesn't provide a lot of
advantages, but, again, having to write 2x less code is just huge. I don't
know Android at all and I released Android version.

------
nathan_f77
The patent stuff doesn't seem very important to me. You might not like it in
principle, but I don't think it's going to affect you.

The author mentions Flow as a typing solution to solve some of the problems
with Javascript development, but didn't like it because you can still write
code that crashes if you ignore the warnings. They also complained about the
lack of immutability, and mentioned Immutable.js, but weren't happy with that.
They went on to say that most of these problems they mentioned are already
solved with libraries, but ... libraries are bad? I didn't really pay
attention to the huge Javascript rant in the middle, but I've heard it all
before, and I totally disagree. I've started to realize that I prefer ES7
Javascript with Flow or Typescript, jest, babel, webpack, etc. I think I
actually enjoy writing it more than Ruby or Swift.

I really like react-native-web [1]. I've used it to build an app that runs on
all mobile devices (iOS, Android, Windows Phone), as well as on the web.
There's a lot of quirks and workarounds, but it was actually a lot easier that
I expected. Even if you just use plain react on the web, it's easy to write
re-usable components and code.

They also mentioned hot reloading. If I wrote an article titled "Why I'm a
React Native developer", the content would just be the words "Hot reloading."
I spent a year developing a native iOS app with Swift, and I never want to go
back to waiting for my code to compile.

[1] [https://github.com/necolas/react-native-
web](https://github.com/necolas/react-native-web)

~~~
inimino
Unfortunately "I don't think it's going to affect you" is not a strong legal
argument and it's hard to dismiss legal risks that so many other companies are
taking seriously. I do like React, but the legal uncertainty is a significant
downside.

------
user5994461
Clearly, that guy despises javascript with a passion. He should get a job that
doesn't require him to ever come in contact with javascript.

------
mjmsmith
Shorter than the React code, I'm not seeing a big win other than the need for
an explicit render() in didSet, which also allows for more fine-grained
control if needed.

    
    
      class ViewController: UIViewController {
        let indicatorView = ConnectivityIndicatorView()
    
        override func viewDidLoad() {
          super.viewDidLoad()
    
          indicatorView.frame = CGRect(origin: CGPoint.zero, size: CGSize(width: 20, height: 20))
          view.addSubview(indicatorView)
        }
      }
    
      class ConnectivityIndicatorView: UIView {
        var isConnected: Bool = false {
          didSet {
            render() 
          }
        }
    
        override func didMoveToSuperview() {
          super.didMoveToSuperview()
    
          isConnected = arc4random()%10 > 4
        }
      
        func render() {
          backgroundColor = isConnected ? .green : .red
        }
      }

~~~
gunn
Here's a more canonical version of the exact same logic in react:

    
    
        const Root = ()=> <ConnectivityIndicatorView/>
    
        class ConnectivityIndicatorView extends Component {
          state = { isConnected: false }
    
          componentDidMount() {
            const isConnected = Math.random() > 0.5
            this.setState({ isConnected })
          }
    
          render() {
            const backgroundColor = this.state.isConnected ? 'green' : 'red'
            return <View style={{backgroundColor, width: 20, height: 20}}/>
          }
        }
    
    
    
    

And here's how I would actually write it in my own app:

    
    
        const Root = ()=> <ConnectivityIndicatorView isConnected={Math.random() > 0.5}/>
    
        const ConnectivityIndicatorView = ({isConnected})=> {
          const backgroundColor = isConnected ? 'green' : 'red'
          return <View style={{backgroundColor, width: 20, height: 20}}/>
        }

------
z3t4
> In JavaScript, functions don’t have a return type, you don’t know what can
> be returned by the function

Do engineers actually depend on the compiler to save their ass and don't
bother looking up in the documentation or reading the source code to see what
a function returns !? No I don't think so. There's a saying that every bug
that ever existed in a static typed language actually _did_ pass the type
checks. If the compiler finds a bug it's rather _luck_ that the two parameters
passed in the wrong order was not both of the same type, and not because of
better language design. If you don't know what a function returns, you can say
"bad documentation", or "bad code", but don't blame it on the language.

------
kevinsd
(Disclaimer: Using RN in production) The author listed some very legit points
that RN is lacking and I share the same pain or complaints. You can beat up
any tech with its shortcomings and that will be a good read. But arriving at a
conclusion that something unjustified is better is logically flawed.

------
z3t4
> What’s nothing?

I know the == operator drives people crazy sometimes, and you are told to use
=== but if you actually understands what == does it's a _convenience_ that
null==undefined so you don't have to type if(foo == null || foo == undefined).
You could argue that having two (or with false it's three) types of "nothing"
is confusing, but for me they mean different things. undefined means it has
not been defined, null means it explicitly "nothing" and false means it's "not
true". And _for convenience_ you can write if(foo) to check for them all.

------
tentativeuser
Is it true that React Native cannot be integrated with an existing Swift/Obj-C
codebase?

For example, say that you want to implement login/register on top of an
existing Swift codebase. This is possible, right?

(May not have understood OP correctly.)

~~~
crispinb
It depends what you mean 'on top of'. If you mean adding some RN to an
existing app, that is conceptually easy but practically quite messy
([https://facebook.github.io/react-native/docs/integration-
wit...](https://facebook.github.io/react-native/docs/integration-with-
existing-apps.html)).

If you mean adding native modules into an essentially RN app, that's
practically very simple ([https://facebook.github.io/react-native/docs/native-
modules-...](https://facebook.github.io/react-native/docs/native-modules-
ios.html)) but still requires some conceptual care (like any API design).

------
betoharres
dude lost me after pointing about IDE. Wtf, this is not an advantage. This
sounds like a "microsoft" arguments. You want to compare productivity? Have
you seen how many ready-to-use components there are in RN community? This is
the real productivy advantage, not an IDE.

But I aggree with all the problems of javascript, they were my excuses to not
learn javascript, and here I am, writting RN apps. Things happens in RN world
man, you gotta move to the winning side and leave your pride. Get over it.

------
z3t4
In JavaScript it's only the primitive objects (Number, String, Boolean, null,
undefined) that are "by value". Everything else is "by reference". And when
you write {foo:1} you create a _new_ object. So it's logical that
array.includes({foo:1}) is false. You can however point {foo:1} to a variable,
and then use that variable as a reference, eg. var foo = {foo: 1};
array.push(foo); array.includes(foo);

------
brad0
Why is it that we have to bring web technologies to the native platforms
rather than using native platforms on the web?

~~~
tuukkah
The web is open, standardised, has the mindshare and the runtime (browser) is
everywhere. There have been initiatives to bring e.g. Qt or GTK to web, but no
success AFAIK.

~~~
brad0
Yeah you're right. Open standards makes sense.

It's a shame that no one takes something like the old Android codebase and
makes it for web in the canvas. Is that even possible?

------
z3t4
You can laugh at JavaScript because of all the fun and stupid things you can
do with it like writing entire programs with just {[( but with meta
programming and operator overloading that is common in many "serious"
languages there are even more "WTF" possibilities.

------
corn13read
tl;dr: I really don't like RN and wasted a ton of time trying to talk people
out of it for mostly unfounded reasons that won't affect 99% of users in any
meaningful way.

------
ojr
If you want immutable data structures with React/React Native learn Redux with
Immutable.js, it has a learning curve but will solve some of your problems

------
bernadus_edwin
When i move to RN, Swift 3 is very slow on build time. Xamarin not support
instant run. So i move to rn, although it feel not complete product

