
Why I'm Not a React Native Developer - nootopian
https://arielelkin.github.io/articles/why-im-not-a-react-native-developer
======
STRML
This is simply a list of things the author doesn't like about JS, very much of
which is practically solved by Flow/TS and ESLint.

He also makes some of the React examples quite a bit more complicated than
they need to be. Declarative UI is very simple!

Here's the same code, using both class and functional styles (whichever you
prefer), in a much more succinct style (11 LOC vs 49):

    
    
        class Root extends Component {  
          render() {
            var isConnected = Math.floor(Math.random() * 10) > 5;
            return <ConnectivityIndicatorView isConnected={isConnected} />;
          }
        }
    
        function ConnectivityIndicatorView(props: {isConnected: boolean}) {
          const color = props.isConnected ? 'green' : 'red';
          return <View style={{backgroundColor: color, width: 20, height: 20}} />;
        }
    

The point is, much like many things in software, it's all about perceptions
and familiarity. He's not familiar with JS, and I don't fault him for that -
it's a quirky language. But for the many, many developers who have built up a
tolerance to JS and built/use tools to tame it, moving to React Native is a
breath of fresh air vs learning Android & iOS toolchains and idiosyncrasies.

~~~
Pfhreak
> This is simply a list of things the author doesn't like about JS, very much
> of which is practically solved by Flow/TS and ESLint.

That's definitely not a fair characterization of this article.

Concerns about roadmap and patent usage show up before any concerns about JS.

Edit: Though I agree, a strangely large amount of the article _is_ dedicated
to "Why I just don't like Javascript."

~~~
pauljaworski
That is a __very __fair characterization of the article - 70% of the article
's content is about why JavaScript is bad.

~~~
coldtea
70% of the content is not necessarily "the most important part of the
content".

2 minutes in a 5 minute animation short are the credits.

~~~
ulisesrmzroche
You know theres no 5 minute animation shorts with 2 minute credits in
existence.

~~~
coldtea
If you ever go to a short film festival, animation or not, you'd be surprised.

Here's a 2:18 animation with 1:06 credits -- way more than the ratio I gave:
[https://www.youtube.com/watch?v=8ZRLlyxvr6E](https://www.youtube.com/watch?v=8ZRLlyxvr6E)

Credits --crew members, voice talent, sponsors, thanks, etc-- can rise almost
linearly with the length of an animation, and even more so with increases in
its production value.

A 5 minute short can have almost the same team size as a feature animation
(which requires > 2 minute credits). The fact that they'll be employed for
shorter time doesn't mean they don't get their names on the credits.

------
cocktailpeanuts
A lot of people here seem to criticize the OP's POV on javascript, but my
biggest takeaway was the more abstract parts of his post, such as patents and
uncertain roadmap. These are very REAL problems.

I am a javascript programmer AND an iOS programmer. I work with React to build
web apps at work. And lately I have played around with react native, but I
felt uneasy jumping ship to use solely react native for the very same reason.

I instead decided to learn Android programming. There's really nothing to lose
going that route (after all, you're learning Java, which is arguably the #1
popular language in the world, so even if you end up giving up on Android, you
still know Java), compared to spending the same time learning React Native
which has very uncertain future (I would trust it much more if it was not from
a corporate entity like Facebook)

~~~
Lazare
> my biggest takeaway was the more abstract parts of his post, such as patents
> and uncertain roadmap. These are very REAL problems.

I would say the patent issue is more FUD than a real issue; he praises Swift
but Swift has a very similar patent grant and termination clause. The key
difference is that the Swift grant terminates if you end up in a patent
dispute with Apple over something related to Swift; the React grant terminates
if you end up in any patent dispute with Facebook.

So the whole issue boils down to "what if you get into a patent dispute with
Facebook over a patent that doesn't relate to their core web UI tech".
Which...I dunno, is that a real concern?

> “nice quantum physics technology you have here, would be a shame if
> something bad were to happen to your app”

Yeah, okay. But if my core business is making apps, then every patent I might
have is likely to be covered by both patent grant termination clauses. So the
issue is...?

(Also, the author is conflating the license to use React with the license to
use any patents, if any, which cover React. If, as is entirely possible, no
Facebook patent covers any React technology, then having the patent grant
terminate would not concern you.)

~~~
cocktailpeanuts
My point was not about the details, but about the uncertain nature of an open
source project driven by a company. The patent issue is just one of the
"symptoms" of this problem. When someone open sources their technology and
adds a set of detailed clauses that adds some restriction (doesn't matter if
it's a "real" restriction or not), it means they couldn't go all out. It also
means as a user, you do have reasons to be cautious about it, not because of
what the license says in detail, but because of the reason behind the
behavior.

But anyway, this patent issue is just one part of the larger issue, which is
uncertainty. When Apple or Android changes the API policy in the future,
you'll be struggling to adapt to the new reality with what you have. Sometimes
it works, but sometimes it doesn't. Currently it does make sense for some
people to build using react native, but if I were you, I would rather learn
Android. Really, if you already have iOS experience, a lot of the paradigm is
pretty similar and it won't be super difficult to learn.

This "cross platform" concept used to be valuable maybe in 2010 when it wasn't
clear what mobile platforms would be dominant (with windows phones,
blackberries, and even samsung launching their own developer platforms). But
it's 2016 now, and we're pretty sure it's either iOS or Android. All you need
is just those two platforms.

~~~
chii
> pretty sure it's either iOS or Android.

it's web, android, iOS, and PC. That's 4 platforms, if you consider web and PC
separate, and more if you consider windows and linux as separate.

Crossplatform is more valuable than ever. But react-native may not be the
answer.

~~~
cocktailpeanuts
The context of this entire thread was about mobile ecosystem. The concept of
"cross platform" only holds when you're comparing two similar ones

~~~
chii
the whole premise (that i m sold on react-native) is that it lets you use code
from your react app and run it natively.

And the concept of cross-platform is not only for "similar" platforms like
mobile, but across disparate platforms, like mobile AND PC. Otherwise, what's
the point of cross-platform?

~~~
cocktailpeanuts
As I said, that's not what people mean when they talk about "cross platform"
in this context. Go to phonegap and see if they support PC. Cross platform
means you should write once and it works everywhere without modifying
anything, just like the web. But you can't be cross platform AND native on
completely different types of platforms, since each has its own distinct
feature sets. You are free to believe whatever you want but that doesn't
really mean anything since you're basically arguing about something that I'm
not even talking about.

~~~
tracker1
And that means that ReactNative is better than phonegap! ;-)

I'm not completely sold on ReactNative compared to Phonegap and Electron as
targets with React web... however, I can indeed see the appeal.

------
franciscop
Please what kind of programmer would ever do this?

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

That is just verbose unnecessarily:

    
    
        this.setState({ isConnected: weAreConnected });
    

And probably not so popular, but this:

    
    
        var color;
        if (this.state.isConnected) {
          color = 'green'
        }
        else {
          color = 'red'
        }
    

Would be simplified often to:

    
    
        var color = this.state.isConnected ? 'green' : 'red';

~~~
kbart
_" Please what kind of programmer would ever do this?"_

I've seen some coding rules/guides that explicitly forbid short form of 'if'
statement usage.

~~~
franciscop
That statement is about the first code block; the second one as I commented is
totally optional and I agree that it might not follow some code rules (;

------
weixiyen
Reasons why I am a React-Native developer:

\- It works, really well.

\- Iteration speed alone has helped us retain at an extremely high DAU/MAU
ratio compared to years past.

\- Both my apps have near 5 star rating across the board, probably the highest
rated in the Sports category since we released, and none of our users notice
that it is a RN app, which is really surprising b/c RN on Android is not up to
par with iOS.

React-Native is not for every scenario, but I disagree with the author's final
conclusion, that "the pros do not outweigh the cons". It's really quite the
opposite in our case. The pros (OTA and productivity) heavily outweigh the
cons.

Would love to see something better come out, but the recommended alternatives
by the author wouldn't make the cut for us.

~~~
macspoofing
>React-Native is not for every scenario

What scenario isn't it for?

~~~
ziziyO
Anything where you need to stay alive in the background and periodically do
something.

~~~
christocracy
Utterly false. Staying alive has nothing to do with React Native or Cordova or
any particular framework. It's about implementing the native APIs that allow
that behaviour.

I'm the author of a couple of modules that allow your RN app to operate in the
background:

[https://github.com/transistorsoft/react-native-background-
fe...](https://github.com/transistorsoft/react-native-background-fetch)

[https://github.com/transistorsoft/react-native-background-
ge...](https://github.com/transistorsoft/react-native-background-geolocation)

Both of these modules were ported from Cordova and have since been ported to
NativeScript.

~~~
ziziyO
Thank you for linking those modules. I'm in the early stages of an app that
will benefit from that functionality and admittedly my knowledge is based off
of the first google result of a search for "react native background
worker/task" ([http://stackoverflow.com/questions/35376690/how-can-i-run-
ba...](http://stackoverflow.com/questions/35376690/how-can-i-run-background-
tasks-in-react-native)). Which of course makes me an expert on the subject in
this day and age.

------
kschiffer
I believe in the end it all boils down to the fact that JavaScript is a
language that wasn't made for the needs of modern day (web) applications, but
since it is still a standard, we need to force it into a form where we can
have best control over its shortcomings. That's why things like Typescript,
Flow and React exist in the first place. I know this article is about mobile
app development, but I think JavaScript would not have the sort of widespread
use today if it wasn't for the fact that we use it for website scripting.

So I guess that developers familiarity with the language is what makes it so
popular (as in often-used) and is also why we suddenly start using it for
arbitrary scripting and mobile app development. The obligatory use of
JavaScript in web development led to a whole range of developers growing
accustomed to it and now, in spite of its limitations, trying to transfer
their ideas to other fields of development.

React Native is just a neat way for JavaScript (React) developers to be able
to script UIs for mobile OS's without changing their toolset. And I think for
that it's perfectly fine. Obviously if you've never been big into JavaScript I
can totally see how cannot make much sense of it all and yeah a lot of the
things pointed out are perfectly legitimate. Yet I still think the question
whether it makes the language unusable for one scenario or the other is very
very opinionated.

~~~
qwertyuiop924
Besides, while JS's problems are very real, they're quite exaggerated. It's
still a perfectly usable language, even without TS and whatnot.

And unlike _some_ languages used for app programming, an error doesn't have
the potential to hand you a segfault.

~~~
tempodox
> ...an error doesn't have the potential to hand you a segfault.

And that is a good thing why? So you don't realise there was an error and your
app runs on in a corrupted state?

~~~
aurelianito
For starters, a huge set of security vulnerabilities are not possible. Ex:
buffer overflow, double free, reading uninitialized memory.

~~~
qwertyuiop924
Precisely. Don't write Application code in a systems language.

------
greggman
The author's rant on JS and npm deps has a point but his rant on typescript,
flow, and other transpilers completely misses the mark. If JavaScript is an
unsafe language and therefore anything that compiles on top of it is unsafe
the same is true of Swift as it compiles to assembly/machine language which is
unsafe. If you consider JavaScript some cross platform assembly language then
there is no difference between the two ideas.

He also rants about using the best language that catches the most errors but
then picks Swift as his solution. I have a feeling there's lots of other devs
that would not rank Swift at the top of languages that catch the most errors
and therefore the author is being hypocritical in ranting that you should
always use the best since they're arguably not using the best.

The article did make some other interesting points

~~~
RodericDay
> If you consider JavaScript some cross platform assembly language

I am so sad right now

~~~
bbcbasic
Why? Some of the transpilers like Typescript are quite light touch.

------
tmorton
Aside from the discussion of JS and React Native, I want to highlight this:

> Perhaps more importantly, your software development platforms also shape you
> as a software engineer. A software development platform encourages (or
> forces) the use of one language over another, prioritises certain
> architectures over others, requires using specific tools and workflows, and
> marries you to an entire ecosystem and its developer community.

People talk about the "right tool for the job" and "good developers are
polyglots." This is true to an extent, but there are still communities with
different priorities, and they often form around languages and tools.

~~~
EdwardDiego
Hmm, communities become less important as languages become more widely used.
When was the last time you referred to the Java community, singular?

Likewise, there's not a single JavaScript community, but there's a bunch of
communities around specific tools and frameworks. As you'd expect.

But I, when interviewing, expect good developers to be capable of learning new
paradigms - the fact that they know nothing but node.js and node.js's ways is
irrelevant, if they are capable of learning.

The author has very low expectations compared to me. And I don't feel I've
been proven wrong yet by any of the hires I said yes to.

------
revicon
tldr; Author doesn't like writing in javascript and fears that Facebook may
some day decide to stop supporting React Native.

~~~
ChrisLTD
Ariel also doesn't like this clause in the React license:

 _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, or take a direct financial interest in, any
Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any
of its subsidiaries or corporate affiliates, or (iii) against any party
relating to the Software._

~~~
ianl_person
To my reading, there are two separate items: a copyright license and a patent
grant. \- The former allows you to make copies of the software \- The latter
protects you from Facebook claiming patent infringement arising from the use
of React Native (aka, Necessary Claims). It doesn't necessarily mean they have
such patents but if they do, you are protected.

So if the reciprocity clause in Facebook's patent grant is a problem, all
recent MIT licensed software out there without a patent grant would also be
off limits.

~~~
Lazare
Yep. And depending on the details of the concern, so would an Apache or
Mozilla licensed project, since they have explicit grants with termination
clauses only slightly narrower than React's.

------
jondot
I'm the author of
[http://programmingreactnative.com](http://programmingreactnative.com),
maintain the [https://github.com/jondot/awesome-react-
native](https://github.com/jondot/awesome-react-native) list and built some
other tools and libraries for React Native, along with a few apps.

Obviously the conclusion that follows is that I think React Native is going to
be a revolution for mobile development. Not only will it succeed, it will get
copied, and you'll have many variants of the same like-minded platform (open
source, developer-oriented, low-barrier language).

Regarding the article, my point of view is that some points in this article
are valid, but are trivially obvious:

\- Javascript is Javascript, take it or leave it. Flow and Typescript is an
evolution that to me looks good. It is one language that was adopted to be
user-facing in React Native. According to Apple's Developer terms 3.3.2 and
3.3.3 only interpreted languages that run on JavascriptCore are allowed to be
pushed to market.

\- You can't know what the future holds. I was part of the Ruby community at
the start, then Node, then Go. I was hard core into .NET, and before that
Java. I saw platforms and technologies rise and fall, and was surprised over
and over. I was much into Silverlight, a technology that Microsoft wanted to
take over native development on the Web. Guess what happened to Silverlight?
THAT was very nasty. We all know how that feels, but that's nothing to
attribute just to React Native.

\- Regarding patents: I believe we will have alternatives to React Native
long-term, with the same properties but we'll still choose React Native :).
However I also believe Facebook doesn't use patents in a bad way that the
author hints at, as far as we know and as far as we've seen. I also met with
core React Native developers, and they're awesome.

Practical advise: I'd suggest for the author to meet with the React Native
core team.

~~~
jjuel
So we will have many variants? Does sound like a classic JavaScript thing to
have many frameworks that do the same thing. Reminds me of this:
[https://xkcd.com/927/](https://xkcd.com/927/)

------
joshwcomeau
Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed
ones, but that's a preference, not a reason to try and say that JS is
objectively terrible.

Same with switch fallthrough, same with error handling, same with half his
issues with JS.

There are some legitimate grievances tucked in there, but the author lost me
by pretending that his preferences were universal.

~~~
SomeCallMeTim
TypeScript is a JavaScript best practice at this point. It's a type safety net
on top of dynamic types, so you get the best of both worlds.

TypeScript has a flag that prohibits switch fallthrough, for instance, though
that's an easy one to set up a linter to catch.

One reason I prefer NativeScript to React Native; they are embracing
TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but
that I freely admit is a preference.

~~~
qwertyuiop924
TS over JS isn't best practice yet: Some of us _like_ dynamic typing.

~~~
kuschku
For what purpose is dynamic typing ever useful except "it’s faster to
develop"?

With a proper type system (see: Haskell, Scala) and parametrized types, you
can do everything that’s reasonable in a dynamically typed language, too.

~~~
evgen
You can do them, as you noted, at a much slower pace. Type systems catch one
class of bugs, and if in your experience these are not the bugs you worry
about or the bugs that cause you the most pain then slowing down development
is a high cost to pay.

~~~
overgard
Honestly I think the bug catching aspect of static typing is its least useful
property. (Useful, but not like, amazing -- you can write assertions on a type
in a dynamic language). I think the good thing about static typing is it makes
a code-base much easier to navigate and much more self documenting. I spend
most my time navigating other peoples code. I know you can get most of the
reliability of static typing with extensive test suites etc., but that doesn't
help my IDE and it doesn't let me look up parameters at a glance. I used to be
firmly in the dynamic camp, but having to maintain other people's javascript
definitely made me do a 180.

~~~
Bahamut
Writing assertions has a runtime cost that isn't present when using something
like TypeScript.

Granted, that benefit is probably minor, but it is a benefit in TypeScript's
favor.

~~~
mbrock
It does have a compile time cost and that's not negligible... although with
all the heavy transpilation going on these days, a bit of type checking might
drown that out.

At a previous job we tried TypeScript but it took around 20 seconds to build
our front end. Since then I hear speed has improved.

------
rco8786
You could have just said "I don't like Javascript" and ended the post there.

~~~
atoko
I feel like this is some sort of signaling, a la 'no true programmer uses
javascript, because types!'.

~~~
matwood
We all use it, but 'no true programmer _likes_ javascript.' :)

~~~
sotojuan
I know plenty of intelligent and accomplished programmers who use and like
JavaScript. I like poking fun at it every now and then, but come on.

------
inian
This article can probably be renamed to "why Javascript is bad"..only patents
and dependencies issues were related to react native..the rest of the article
was about how Javascript sucks..and I think developers are already equipped to
take the call if they want to use js on a large project or not..

------
brhsiao
As someone who loves React, the hardest thing about it for me is debugging.
I'll get some error about how renderComponent doesn't accept null values or
whatever, and when even the outermost error is so cryptic, the stack trace is
even less helpful. Is there a conventional solution to this I'm not aware of?

~~~
darkmarmot
As someone who uses a different component-based js framework, can you not just
put a breakpoint in the chrome dev tools on the renderComponent method for
that component?

~~~
larsnystrom
renderComponent is not part of any of your components. I think the React
equivalent of what you mean is the render method of a component.

The problem I think the OP is talking about is when there is an error thrown
somewhere in the react library code (e.g. in renderComponent) and the stack
trace doesn't even touch any of your code. That makes it really hard to find
the fault behind the error.

This is a lot more common with libraries like RxJS, but I've seen it with
React as well.

The only way I know of to deal with these situations is to put console.log
calls everywhere in my code until I've narrowed down the source of the bug.

~~~
darkmarmot
gotcha, thanks!

------
browniefed
React Native Core Contributors responding and agreeing with some of the
points.

[https://www.facebook.com/groups/reactnativeoss/permalink/159...](https://www.facebook.com/groups/reactnativeoss/permalink/1593579080938720/)

------
sebastianconcpt
React "componentization" is nice. For me there are two things that makes it a
non-starter: 1. That legal clause mentioned in the article and 2. The
complexity of learning this platform is the same as learning the native
without the same benefits on the control over the hardware (actually with
added complexity potential lack of control)

------
__derek__
This is a good post up until the rehash of JavaScript's sins.

~~~
leonatan
It picks up later on. I too had issues with some of the JS stuff, but it's
worth continuing reading. Also worth to take a look at the references.

------
vikeri
For all the hate of JS, I'm developing a RN app in ClojureScript, so I rarely
touch JS and instead use what I percieve to be a nicer language:
[https://youtu.be/6IYm34nDL64](https://youtu.be/6IYm34nDL64)

------
chukye
The most part of cons is criticising JavaScript and NOT React Native. I know
how JS works, and I LOVE IT. The only part of the post that I liked is when he
talks about the license, all the rest is just bullshit from a person who don't
like JS.

~~~
pekk
It's not bullshit if it's a valid consideration when you are trying to build
an app on say iOS and weighting it against say Swift. How many times does this
need to be said? It depends on what you are trying to do and what you want.

~~~
chukye
Ok, this is a good point. But, the author just point out the quirks of JS
language, and not things about the RN itself. Would be more fair if he pointed
out the quirks in python or had focused on the RN. All he says about JS is
very well known and is there since 90s. Also, he is saying that its not safe
because he can't understand and workaround with the pitfalls, JS has a lot of
problems, but also has a LOT of great solutions for them, and by that this not
means that the language is not safe, just means that its harder to work with.

------
tboyd47
This article is beautiful.

I am not a React Native developer, but I am a React Web developer (not by
choice). The author summed up my feelings about React and JS in general so
eloquently. The Swamp Castle and Freedom from Digging bits were so on point.

I am betting that my comment will get buried in the bottom of the comment
avalanche, but if the author is reading, thank you for making my day!

------
doozy
I evaluated React Native for a project and decided to go with NativeScript
instead for a number of reasons:

1\. RN releases a new version every 2 weeks breaking my app every time. NS is
a lot more conservative between releases.

2\. I don't like mixing presentation and logic, RN encourages doing so, NS
does not.

3\. TypeScript is a first-class citizen in the NS environment, it is not in
RN.

4\. Angular 2 > React

5\. NS created a smaller executable with better performance than RN for my
test app.

6\. I couldn't get RN to work with one of my older devices (KitKat), and even
though dozens of developers had already reported the issue, they don't care.
NS worked in the same device just fine.

7\. All the tooling around the RN ecosystem is very confusing.

~~~
msie
Another vote for 7): I tried a little project in React Native and was
intimidated by all the tooling and build steps needed to get my project
running on iOS. To be good with React Native you will have to be proficient
with all the tooling and all that seems to be a shaky foundation. There are
lots of parts that can be updated and can break your project (I say in a vague
way).

------
dahdum
Unless I'm wrong, the only listed alternatives are both paid and closed
source. Xamarin (requires VS Pro) or Appcelerate (requires
$480-$1200/year/developer).

~~~
matwood
I believe Xamarin is now free post the MS acquisition with various parts and
pieces even becoming open source:

[https://blog.xamarin.com/xamarin-for-all/](https://blog.xamarin.com/xamarin-
for-all/)

~~~
dahdum
I was actually looking here:
[https://store.xamarin.com/](https://store.xamarin.com/)

Apparently the free version has usage restrictions? I do consider free w/
Visual Studio Pro license not _really_ free.

EDIT: The licensing pages are confusing but you're right, my mistake.

~~~
romanovcode
No, it's completely free with VS Community (which is also free). And you don't
have to pay if your company has 5 or less people working on it. You also have
to pay if you have 250+ computers/people employed or your revenue is 1m+/year.

Sounds pretty reasonable to me.

------
iOSGuy
I use React Native and he's mostly right. Coming from the perspective of a
native platform, this ecosystem is bat shit insane. It's harder, full of
pitfalls, rife with complications, and rickety as all hell.

However, there are also some pretty excellent benefits that come with all the
Bad of React Native and JS so for the moment, it can be very much worth the
trade offs. I've been working with it for over a year, and for now I'll be
sticking with it.

------
bikamonki
Could FB plug the cord on React once it does no longer align with its core
strategy? Sure, it did it with parse.com without the least concern for the
community of users/clients. The apology was to leave behind a half-cooked open
source version of parse server.

The exact same thing could happen to the React community. I'd say stick to
true open source projects and descentralized communities.

~~~
mbrock
What's not true about the open source of React?

~~~
UweSchmidt
Developed by a company, if they stop it's still open source but who will
maintain it? Linux is "truer" open source since it's all volunteers from day
1.

------
caub
var a = 0; var b = -0;

console.log(a === b) // true

console.log(1/a === 1/b) // false

That's perfect math you mean, of course -Infinity != Infinity, what did you
expect?

I think you should rather think harder, learn math possibly, and your 'safety'
problems with arrays are not problems at all, it's the opposite for other
people

~~~
StyloBill
> I think you should rather think harder, learn math possibly

Oh the irony, when stating that 1/0 = infinity. If you'd learn maths yourself,
you'd know that 1/0 is undefined.

~~~
caub
yea 1/x is not strictly defined for x=0, but you can extend it in ℜ ∪ {+∞,-∞},
I don't know your math background, but 1/-0 could make you think of limits:

1/0 is like 1/0⁺ (limit of 1/x in ]0,+∞[ when x->0) == Infinity.

1/-0 is like 1/0⁻ (limit of 1/x in ]-∞,0[ when x->0) == -Infinity.

1/Infinity is 0 ....

0/0 is however an indefinite form, so it's NaN

so the behavior of JS makes sense

And even if 1/0 and 1/-0 returned NaN, they wouldn't be equal to each other
too

------
minitech
> JavaScript allows for objects to be left in an inconsistent state right
> after being created, as their properties don’t need to be initialised.

No, you just forgot to put `this` in front of `width` and `height`. (Arguments
do default to `undefined`, though.)

------
Codestare
I'm a skeptical native mobile developer.

What are some examples of good apps currently in the store, written in React
Native?

~~~
romanovcode
There are none, really. Maybe Discord? Other than that there are no widely
known apps that uses React Native.

~~~
gagege
Who said "widely known"? There are tons of "good" apps.

------
wmil
This is a nit pick, but isn't his "Ambiguous curly braces" example actually
breaking due to automatic semicolon insertion?

return {{a: 4}}

Isn't valid anyways. ESLint easily flags it as an error.

~~~
SomeCallMeTim
Exactly: Linting rules requiring semicolons should be considered a best
practice.

But I think TypeScript should also be considered a best practice, and between
the two that would solve pretty much all of his complaints.

Well, that and using "==" to compare to null, vs. "===" to compare to
everything else. But the linters all can make that distinction as well.

But he explicitly hates on linters in the article as well. And dismisses
TypeScript and Flow ... because his coworkers aren't being forced to use it?
_THAT_ is the real problem, I think...

~~~
wmil
For anyone else reading this in the future, I should mention that the ESLint
'no-unreachable' rule will catch this even if you don't require semicolons.

~~~
SomeCallMeTim
Good point!

Didn't say this explicitly, but TypeScript will, by default, prohibit
unreachable code as well. [1]

[1] "allowUnreachableCode" defaults to false:
[https://www.typescriptlang.org/docs/handbook/compiler-
option...](https://www.typescriptlang.org/docs/handbook/compiler-options.html)

------
raspasov
Like JavaScript? Use JavaScript. Don't like JavaScript? Use ClojureScript.
Problem solved :)

------
spasquali
These "JavaScript is stupid, why don't you all see that!! Why! Why! Why?!??!!"
rants are really entertaining nowadays. The author has also invented a
(perverse?) extension of Atwood's Law (which law predicted React Native):
anything that can be blamed on JavaScript will be blamed on JavaScript. If
JavaScript ran for president it would be Hillary Clinton, and every other
language would occupy one thread on Trump's Toupee.

------
adamlett
I love this quote from the article:

"The fact that millions of drivers productively drive cars without wearing a
seatbelt isn’t a good argument for cars with no seat belt. Similarly, the fact
that millions of JavaScript developers productively use an inherently unsafe
language isn’t a good argument for the use of unsafe languages."

------
jayajay
This is very ominous. In other words, don't build a RN app because, if it
takes off, Facebook can copy the business model independently and claim it as
their own. And, if you try to do anything about it, your license to use RN is
revoked, rendering your app as nothing more than a petty copyright
infringement.

If you're going to RN, go Pure Native at the same damn time ;) It's awfully
ironic since they market RN to rid us of the need for Pure Native. Or, is it
ironic? It seems this clause and their marketing efforts are truly shield and
sword. I'm not really surprised; it's a very cunning way to hijack ideas from
other people.

I have used RN, though, and it's a blast to develop with it. Thankfully, none
of my kooky ideas are going to be important enough for this fine print to
apply to me.

------
RussianCow
Is anyone using TypeScript with React Native? I'd be interested to see how
easy that is to integrate.

~~~
pier25
In that case it would probably make more sense to just use NativeScript
instead of React Native.

[https://www.nativescript.org/](https://www.nativescript.org/)

~~~
RussianCow
NativeScript doesn't have tight integration with React, and I don't really
want to build that layer myself.

~~~
SomeCallMeTim
Angular 2 is pretty awesome and faster than React.

~~~
gareim
Source on that speed claim, please.

~~~
SomeCallMeTim
I can't find the benchmarks that I'd based my comments on to be honest, and I
have to get back to work. :|

From what I remember, the final version of Angular 2 added a lot of
performance, which pushed it ahead of the latest React in performance.

I did find this:

[http://webscripts.softpedia.com/blog/recent-benchmark-
shows-...](http://webscripts.softpedia.com/blog/recent-benchmark-shows-the-
speed-of-angularjs-2-499638.shtml)

But the Auth0 benchmarks disagree and show React is faster:

[https://auth0.com/blog/more-benchmarks-virtual-dom-vs-
angula...](https://auth0.com/blog/more-benchmarks-virtual-dom-vs-
angular-12-vs-mithril-js-vs-the-rest/)

Angular 1 is terrible performance-wise; that much is certain.

------
dustinmoorenet
There is a bug in his code in the `Unsafe initialisation` section. He tries to
access variables that are not defined in that scope. A linter would have
caught that.

Javascript is like democracy. It works best when:

\- lots of people participate

\- we understand its warts

\- it's allowed to evolve

\- the powerful aren't allowed to write the rules

------
themihai
Ok, so to 'fix it' we need React in Swift(instead of JS) without the facebook
license clause. It sounds like the next UI framework. Unfortunately you can't
have it all because Swift doesn't work on browser(yet, wasm will make it
possible)

------
pacomerh
The alternatives mentioned here are not really of the same type. A better
example of an alternative would be something like
[https://www.nativescript.org/](https://www.nativescript.org/)

------
drinchev
I was hoping to read more about performance. React is a resource hog for
complex state and no 'componentShouldUpdate' method defined.

I will be very happy to see an app in React Native, just to check if it is as
responsive as Objective C or Swift.

------
jbhatab
Article feels clickbaity with some points that have been addressed and
discussed thoroughly already. These are known cons of using a javascript
framework that compiles to native.

If you just want something easily replaceable, use something like cordova.

If you want perfectly native and guaranteed support, use the native SDKs.

If you want simplicity with a javascript framework that compiles to native
with the concerns of it being made by facebook then use react native.

React native solves a lot of peoples problems especially if they are starting
an app from scratch.

------
qwertyuiop924
The legal concerns are legitimate, but frankly, I am unconvinced by the
criticisms of JavaScript: There are well-known, well-designed tools like
ESLint, and if you like types, Flow and TypeScript, which can mitigate the
issues. That's more than you can say about Java (COBOL 2.0, now with a bevy of
cargo-cult OO that makes things more overly complex), or Objective-C (All the
safety of C, with similar OO problems, and a weird syntax that very few people
like, and of course, no GC).

~~~
GeneralTspoon
This comment is flaming on Java and Objective-C, seemingly without having the
experience to back it up.

For instance, nobody uses Objective-C for iOS development any more (see:
Swift). And modern Java is a decent language to develop in (with Rx and the
like). You can even develop for Android in kotlin, which gives many of the
advantages of JavaScript, but with a static type system and deep IDE
integration.

~~~
qwertyuiop924
I was exaggerating, but the point was that the other app development languages
aren't without their flaws.

I won't argue with you on how good the languages are. It's a matter of
opinion, and I'll never change your mind.

Besides, establishing one langauge as better than another was never my point.

------
mastazi
From the article:

> Compared to React Native, both Xamarin and Appcelerator have better
> prospects at longevity. Appcelerator (the maker of Titanium) (runs on apps
> installed on 350 million devices) was acquired in January 2016

Last time I tried (circa 2013) Appcelerator seemed a bit unpolished and the
tooling was sub-par (I vaguely remember of some hacks needed to get their
custom IDE runnning on Windows), I would like to know how are they doing now.
Could anyone familiar with it summarise their recent developments?

------
enturn
It would be good to have when the article was written/updated on the page. I
found Sep 22, 2016 in the changelog (link at the bottom) for first commit.

------
andrepd
To add to the list of javascript gripes, performance is terrible. For the web
we can sort of excuse it because ok, it's running in a browser and has to be
cross platform and interpreted and etc. But for a native app? No excuse to
burden the user with a slow, sluggish, resource and battery draining app when
a compiled native app can be snappy, quick to load, and light on the CPU.

~~~
pitaj
Have you tried it? Unless you're handling custom animations in the main
thread, the UI feels exactly the same as native.

------
gorkemyurt
Ability to update your app over the wire with React Native is a massive
advantage overlooked in the article. (via Codepush or something similar)

In big companies app releases are a huge problem when 100+ committers and tens
of features are released to the same app sometimes within the same app update.
React Native has the potential to enable feature teams independently update
the app.

------
Sagiri
> There is no mechanism for you to mark a function as potentially crashing
> your teammate’s code or for specifying how to process an exception.

Maybe I'm misinterpreting this, but is the author actually advocating for
Java-style checked exceptions? I can't even remember the last time I heard
somebody say something positive about them (other than just now, possibly).

------
Legogris
Maybe nitpicking, but the author states that "Your codebase can now create an
app that can run on millions of additional devices, and you’ve increased your
outreach by several orders of magnitude."

Yeah, Android is growing, but iOS still has substantial market share.
Switching to React Native will definitely not give a > 100x increase in
outreach.

~~~
striking
The Android market share is >60% and rising, though. Not sure what you're
talking about. [https://bgr.com/2016/06/02/apples-mobile-market-share-
sees-b...](https://bgr.com/2016/06/02/apples-mobile-market-share-sees-big-
drop-in-may-as-android-skyrockets/)

You're right about the last part, though. You won't _literally_ get a _100x_
increase in reach from _just switching_ to React Native. Being able to develop
on two platforms at once might help a little bit there, though, which is what
I think the author was trying to say.

~~~
Legogris
The nitpick being that usually, one order of magnitude = 10x, two orders of
magnitude = 100x, and so on. So it's a very exaggerated statement if taken at
face value.

------
leshow
This post is completely false, you can absolutely build a safe language on
unsafe foundations. Swift is compiled to assembly, which is unsafe, yet it
provides a 'safe' interface (not as safe as Rust, but still).

Similarly, Flow/Purescript/Elm have every ability to provide a safe interface
to javascript.

------
wczekalski
I wrote a counterargument to it. [http://wokalski.com/Why-Im-not-afraid-to-
develop-in-React-Na...](http://wokalski.com/Why-Im-not-afraid-to-develop-in-
React-Native/)

------
qaq
Granted Swift is a nice language TS or JS + transpiler + flow is decent and
unlike Swift you can actually utilise multiple threads :) The patent stuff is
moot point Apple has about the same language in their license.

------
betenoire
> This allows over-the-air code updates. Any changes in your JavaScript code
> can be instantly pushed to your users while the app is in production

Is this really true? Or is the author referring to the dev. edit/view loop?

------
kowdermeister
You probably shouldn't ever use the phrase [random-technology] developer. It
puts you in a box that associates you with all the shortcomings of the given
technology.

------
formula_ninguna
We have PureScript which is statically typed, pure functional language
compiling to JS, can't it be adopted for React Native development somehow?

~~~
bbcbasic
You really need to check out Elm.

It's an ML-like language with built in functional reactive framework similar
to React, but built to work naturally with the language rather than requiring
the FFI binding you'd need if you use Purescript.

~~~
pka
Elm's type systems is really constrained compared to PureScript's. It's great
for people coming from JavaScript, but not so much for those coming from
Haskell.

Also, you still need FFI in Elm. elm-lang/virtual-dom is basically just a
wrapper around the native virtual-dom library. Also, afaik there's nothing
like react native for virtual-dom.

~~~
bbcbasic
I was under the impression that Elm rolls it's own virtual-dom?

~~~
pka
iirc they scrapped that in favor of virtual-dom a long time ago.

------
kimshibal
Alibaba's Weex is better than React Native.

------
swsieber
After reading this and other comments here, I sort of just wish there were
Haxe bindings for to the React Native stuff.

~~~
gagege
That would be cool. What I really want for Christmas this year is React Native
but with Elm instead of JS!

------
avocade
Probably the best dev article I've read this year to date. Have youz a
newsletter? :)

------
draw_down
I think it's a really nice way to make an app :)

------
thwee
We haven't moved much from MVC apps, have we?

~~~
romanovcode
Nothing wrong with MVC.

------
_pmf_
Idiomatic React looks like a horrendous mix of PHP3 and VBA.

------
tracker1
Responses to each category...

1\. uncertain roadmap

It's open-source, and given the amount of contribution and efforts to get
third party targets for windows, ubuntu and mac I seriously doubt it's going
anywhere any time soon.

If you look at React proper, it's not much different, and that has gone
incredibly well... React has some of the best diagnostic information in terms
of error/warning states of any web ui tooling I've used.

2\. Patent grant

The reason for the separate patent grant is because a copyright license,
particularly a permissive one like BSD (or MIT, ISC, etc) do not specify
patented parts of the application. MS-PL iirc was basically an MIT-like
license with a patent grant (with nuclear deterrent) attached.

Most large companies that are publishing larger open-source tools have similar
clauses to their patent grants. That said, I'm against software patents as a
rule, so this concerns me very little.

Hell, Apple's swift license has a similar provision...

    
    
          ... If You
          institute patent litigation against any entity (including a
          cross-claim or counterclaim in a lawsuit) alleging that the Work
          or a Contribution incorporated within the Work constitutes direct
          or contributory patent infringement, then any patent licenses
          granted to You under this License for that Work shall terminate
          as of the date such litigation is filed.
    

3\. JavaScript

I won't argue the merits of JS over other languages... I will say that I've
enjoyed working with it, it's my favorite language, warts and all, and that
you can write horrible code in any language.

There's TS, flow, eslint and many other tools to help with issues there.

The cartoon illustration predates npm, es6 and a lot of other work towards
making things a lot better. Also, you've already invested into React*, then
you may as well invest in babel/es7+, redux and a handful of other options
that do add a direction.

3\. Dependencies

That's the nature of large software projects... also, with node ecosystem, it
means that React doesn't have to re-create a lot of work that has already been
done.

4\. Alternatives

As to Xamarin and Appcelerator, what about web and desktop targets? You will
have to re-create a large amount of your codebase, and even non-ui bits in
order to support them.

SUMMARY:

In general, I understand your arguments... but you're missing one... You can
use a single unifying platform and language for all of your front end and
back-end code while being able to target pretty much every platform in wide
use with minimal changes.

The JS/npm ecosystem is one of the most vibrant in developer history, while a
mixed blessing sometimes, it does work incredibly well.

------
elcct
JavaScript has its share of bad things but that's mostly solved by good
tooling. I think Java or ObjectiveC feel too "heavy" for UI development. React
makes it simple and even with its downsides in my opinion it makes other
technologies no longer relevant in this domain .

~~~
romanovcode
>it makes other technologies no longer relevant in this domain

Are you really trying to say that React Native makes Java not relevant for
Android and ObjectiveC/Swift not relevant on iOS. Maybe you are correct if you
want to build Hello World application, when you will be needing something more
optimized sooner or later you'll have to rewrite it in Java/Swift.

~~~
elcct
Do you have any specific example where Java or ObjectiveC/Swift would be of
better use?

~~~
romanovcode
Anything that requires some kind of processing like, for example facebooks own
Instagram.

~~~
elcct
That's fair, but why would you do Instagram like processing in the UI? I'd
rather do native library and call it to do the work...

------
thedonkeycometh
tldr; javascript and facebook

------
joshkpeterson
Author says the bad outweigh the good, but we haven't fully evaluated the
good.

So, question for people who use React Native - how long does it take to go
from [100% front end developer familiar with React] ...to [writing solid
native apps] with React Native? And how much platform-specific knowledge
outside of RN do you need to absorb in order to do this well?

