Why I'm not a React Native developer

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

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
  })

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.

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.

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.

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.

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!

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?

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.

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.

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.”

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...

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

>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?

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.

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 :)

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

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.

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).

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.

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

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.

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
    }
  }

> 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.

(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.

> 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.

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.)

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.

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);

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

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.

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.

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

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