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.
The "concerns about patent usage" is a tired trope as well.
Yes, if you use React you're basically agreeing not to sue Facebook over patents. Except if Facebook was acting in bad faith they'd probably have enough patents you could be found in violation of to ruin you anyway. If your software is non-trivial, it's already violating patents you probably never even heard of.
But the real kicker is that if you're not using React you're probably already using open source software. And in the JS ecosystem that probably means you're using software under MIT, BSD and ISC licenses, which have no patent provisions whatsoever.
Fun fact: AngularJS uses the MIT license and does NOT contain a patent grant whatsoever. If you use AngularJS, Google can sue you over any patents it holds that are relevant to AngularJS -- they don't even have to wait until you sue them first.
Ember? Same thing (MIT license without patent grant).
jQuery? Although it was dual-licensed as MIT/GPL at some point it's now only MIT-licensed and again contains no patent grant.
In other words: unless you have an explicit patent grant, you're at risk of being sued by the owners of whatever patents you happen to be infringing upon. The only difference is that you're entirely reliant upon the goodwill of the patent owners while React explicitly shields you unless you sue Facebook over patents.
The patent retaliation is more broad than the provision in the Apache license though, which basically only revoke the patent grants for a specific work if you sue over patent infringement in the same work.
Yes, I actually wrote a paragraph on Apache/GPL/MPL patent grants which I deleted before submitting because it's really not relevant to the argument.
React, like most JS projects, is licensed under an MIT/BSD style license (they're too similar to be worth the distinction in this context).
The alternative to having the FB patent grant wouldn't be to have the Apache 2.0 patent grant. It would be having no patent grant, as is the case with AngularJS, Ember and jQuery.
Which is completely beside the most important point: if you don't use React, you might be still affected by React-related patents owned by Facebook and there's no patent grant preventing them from suing you -- and this holds true for all patents owned by everybody else.
The default for JS projects is no patent grant. FB is actually more benign than any of the alternatives by providing a patent grant at all.
Not only is the argument entirely theoretical (If FB doesn't sue you over React patents, they might still sue you over non-React patents or someone else might sue you over React patents FB doesn't hold) but it's also invalid (FB doesn't benefit from offering a patent grant compared to not offering a patent grant -- which would have been the default for open source projects like React).
If you just want to argue that FB could have done more, yes of course they could have. But that's like shouting at someone giving you a free penny why they don't give you a free dollar.
So I'm suddenly very interested after hearing about this issue. The discussion always seems to be about Facebook suing me, assuming all is fine because why would I sue them?
The problem is the startup I work for relies on patents for a big part. And if we use any Facebook stuff, which I actually wanted to do as the main developer (react and react-native), they can use our stuff without caring about our patents! Because we can't sue them!
So basically, with that license Facebook on the one hand protects itself against patent trolls. Good, fine.
On the other hand though they grant themselves the right to use any patent of any company that uses their products, because you can't sue them any more! No? That's how I read it after having read a lot of discussions, none of which talk about that major issue, because for most people in this discussion defending their own patent(s) against Facebook is not an issue, so the discussion is very heavily one-sided towards people who don't have that problem.
If FB has patents that cover parts of React, the same patents also cover similar parts in other projects, including your own.
By using React you prevent FB from using those patents against you within the project in which you use React instead of your own analogous code.
They can enforce their patents against you if you infringe on them in your code. They can't enforce their patents against you if you infringe on them by using React.
This is a protection you only get by using React. And it's the only thing that changes if you sue them over patents.
The only difference is that if you don't use React, depending on the exact patents, they might not be able to determine you are infringing on their patents without looking at your code (whereas if you use React they know which of their patents cover React).
But as I said, this "drawback" really pales in comparison to the very real risk of infringing on patents without even using React in the first place. Facebook might hold the patent for some ubiquitous aspect of your application and they could still sue you over that if they want to at any moment.
That said, if you run a software company and intend to sue Facebook over patents, you better believe that they have an arsenal that can take you off the market for good if they want to.
Besides, why would you want to use open source software created, maintained and sponsored by a company you're planning to sue?
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.
It is but not due to `Type errors`, `Lack of function signature`, `Immutability`, `You can’t trust arrays`, `Unsafe initialisation`, `Optional curly braces after an if`.
You should read @pluma's explanation of the patent grant. I think its purely a misconception that's unfortunately been regularly repeated.
> Then why don't you drink this glass of 70% orange juice and 30% motor oil, since by your definition it's "simply orange juice".
I think a more proper correlation of your analogy vs OP's argument would be if you held it up and claims "why I won't be putting this motor oil into my car" and OP pointed out "that's because it contains mostly orange juice." Its intended to be an article about the con's of React Native, but is mostly an article about the cons of Javascript. Its a very well written article and (imho) its best parts are the concerns of long-term development of an entirely distinct ecosystem.
Not sure I follow your orange juice / motor oil rebuttal but I'm going to focus on the more substantive portion of this interchange...
It's purely a misconception in the same way that 30% motor oil is pure orange juice -- which is to say, it's not a misconception, by my reading. I wonder what my IP laywer would say about it, will post if I decide to ask.
Unless I am looking at the wrong comment, @pluma's explanation is just that it's not a problem as long as you don't sue Facebook. But this is equivalent to saying that as long as you give up your only recourse in the event FB violates your IP, you'll be fine. To me it seems like a mentality that makes sense primarily if a person doesn't ever expect to do anything worth patenting, or doesn't ever plan on patenting for some other reason. Don't sell yourself short.
I definitely glossed over the patent issue a bit and appreciate the comment.
> doesn't ever plan on patenting for some other reason
I personally don't believe patents, outside of a few very special circumstances, should be allowed to exist. The idea that Facebook could copy one of my ideas and out-compete me based on their size is, imho, a perfectly reasonable thing for them to do. That being said, the current environment seems to demand that one patent any and everything they can as a pre-emptive defense. Hmm.
Yes, but I was addressing the issue of writing JavaScript, not using its ecosystem. And the lack of a high quality standard library is elegantly solved in ClojureScript by using the Google Closure library.
WRT the Patent concern, you'd be hard pressed to find ANY open-source tool from a large company that doesn't have similar provisions, including Swift's Apache license itself...
As to the roadmap, it's open-source with a vibrant community, if FB steps down, people in the community can fork, step up and continue maintaining... That's the whole reason behind open-source is that you can continue it.
Also, re: your edit.. yeah, far too much... yes JS has oddities, but the null reference issue is present in most OO languages, not to mention a lot of the other issues are well known and/or present in a lot of other languages as well.
Most JS specific oddities can be warned against with linters, and you can use TS/flow if you really want type checking at build.
> JavaScript’s deficiencies seem to impress everyone except JavaScript developers, for whom the aspects of JavaScript that I outlined above are not awful warts, they’re “quirks” or “gotchas” that you, not your language, have to be on the lookout for.
I think his point is that calling JS "quirky" makes it sound benign, or even cute. However, JS's quirks are actually serious shortcomings compared to other languages.
For native iOS and Android developers React Native has a huge intrinsic appeal, for all the reasons he outlined at the start of the post. It's really tempting. Plus, the enthusiasm and scale of the JS community can sometimes ovrshadow concerns non-JS devs have about the language.
To me the post seems helpful. From my experience React Native will certainly not be all puppies and roses for people coming from Java, Swift or Obj-C.
>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.
This is a lot more than "simply a list of things the author doesn't like about JS". The first part of the post in fact is totally orthogonal to JS, and all about React Native as a platform/project.
The anti JavaScript ranting is tedious and redundant, however he points out that virtually no React Native code uses Flow, etc., so it's an unused solution. The point about React having hundreds of dependencies is also well taken.
While I'm at it, I find the graphs towards the end claiming, for example, that using Xamarin (or Appcelerator) is more productive than React Native, or implying Swift is barely shy of perfectly safe to stretch credulity.
Finally, Javascript's "slow" state of development is a feature as well as a weakness, just as Swift's rapid pace of development is both a weakness and a feature. React itself progresses at a breakneck pace.
I actually find it ludicrous the author is complaining about JS's development as a language being too slow. Just the other day I presented ES2015/2016 and the upcoming changes scheduled for 2017 to a room full of JavaScript developers and the general feedback was that JS was changing too quickly.
The reason ES2015 was so huge and so delayed was actually that ES5 was pretty much the lowest common denominator everyone was able to agree on after the proposals for ES4 went up in flames. ES5 is necessarily incremental and ES2015's delay was mostly caused by the repercussions of ES4's failure -- ES4 failed because it valued innovation over backwards compatibility.
I mean TC39 has announced that they will make a new release every year, batching whatever proposals are stable at that point. How can anyone call that particularly "slow" with a straight face?
It's almost like he wrote it in the most obtuse way possible to prove his point. Unless he writes like that normally; If so then I can see where he's getting all these errors from.
It didn't need to happen in componentDidMount with multiple calls to setState. If it's not getting info that it would only know after mounting, it could have happened in the same line that isConnected is initially defined within the constructor!
For that matter, FB encourages the use of unidirectional workflows and simpler components... which means it could have been a pure function receiving props.
Right, but that would almost certainly be a root-level property in any real app. In any case, it's still awfully verbose and confounding for little reason.
I for one enjoyed spending 70% of the time reading about how JS sucks. It's good to be reminded now and then. If I'm chopping wood for years with a dull axe, I get really strong, and good at swinging a dull axe, and at performing superhuman feats of adaptation - adjusting myself and my attitude to using a shitty tool. Maybe even, like Stockholm Syndrome, I come to enjoy it.
Do I resent the guy who comes by once a year and reminds me chainsaws exist? No I do not.
Fair enough... I find it ironic I left the world of .Net and C# behind for node, and am MUCH more productive in node. And he's recommending the reverse.
That said, some of the more recent changes from MS have me interested in .Net again... I've even played around with some of the core/mono onbuild docker containers, which wasn't a bad experience at all.
> 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.
One of shortcomings of language listed by author is precisely this: shortcomings in language are not fixed by fixing the language but by adding new community-supported library.
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)
> 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.)
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.
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?
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.
> 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?
Yes!
On one hand, tons of HN commenters claim to be opposed to 1) NPEs going after smaller software concerns 2) giant ecosystem software vendors being the only choice when it comes to mobile/web technologies, but then this amateurish ¯\_(ツ)_/¯ mindset carries the day on easily graspable concepts that directly affect the likelihood of patent infringement.
> 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...?
Given the increasingly broader markets that Facebook, Amazon, et al. want to break into, the issue is for businesses whose core business doesn't relate to apps but that still want to leverage modern software (aka all of them).
Stop brushing off issues you don't understand and calling them FUD.
We've been here before. The patent protection used to go one-way, but now goes both ways after the issue was raised. Most open-source code comes without patent grants of any kind, so use would automatically infringe which is a far worse situation than here. More pragmatically, few companies could actively pursue a successful patent war with Facebook because the company would run out of capital before the suit was settled. That said, I haven't seen evidence that Facebook actually owns any patents related to React which makes the grant somewhat moot.
> Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminate under section (i) of this paragraph due to such counterclaim.
I agree with you. I have almost no iOS or Android programming experience. I built my own little work out app in react native, because it's a tech stack I know pretty well. But I do run into issues where it stops working, and I need to do a bunch of dependency updates and rebuild it. Might be worthwhile for me to just learn Swift and the UIKit APIs.
When I started my current job, I was talking to our tech director on how ive been using react native a bit. Been meaning to do an internal demo for it. I do find some of the development tools awesome, but really when we already have experienced iOS and android devs in house, why not keep growing in that area instead? React Native could be a way to do some quicker business wins, with clients that need cross platform in a short time frame. But I'm not convinced it's the right solution outside of that.
At first I downloaded and watched some tutorial videos online, but a lot of them were outdated and actually did more harm than good (for example talking about ListView when nowadays you should be using RecyclerView, etc.) so I got a book that's pretty up-to-date (published in 2015), and that helped me a lot.
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 (;
Before 1900 Frege pointed out that we don't need to say, "The sea is salty is true"; we can just say "The sea is salty". A century later it still hasn't sunk in.
- 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.
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:
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...). Which of course makes me an expert on the subject in this day and age.
Uh no. Your application can be completely shut down and push notifications will still arrive on the phone for Android, iOS, and Windows Phone. Once the app is open, you load the new bits of the conversation.
Stuff in the background would be like video/audio calls, playing music, actively monitoring motion/gps (MapMyRun/Ride/Swim/etc), and a few other things that escape me at the moment.
On android at least, if you need to play music, couldn't you do that in a background service written Java and then have a UI written in RN that connects to that service?
I actually meant more along the lines of if you already have 2 very successful iOS and Android apps and a process to release quickly and you've already found real meaningful traction. In this case, the cost of switching is probably not worth it versus continuously improving your existing apps.
If you are looking to release games quickly, the choice is generally Unity, although I hate how all the Unity games take forever to load, but it's a great way to get your game out quickly, and the good games will overcome the load times issue.
Definitely. Unless you have an extremely simple game, you're probably not even using the OS's built in UI framework; something like Android NDK[0] and whatever its iOS equivalent is are more suitable.
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.
It's worth noting, that given the early days of the web... It's just as likely we could have perl in the browsers, and I'm certain people would bemoan that as much or more.
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
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.
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.
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.
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.
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.
...but so many smaller companies and startups use React. Personally all of my employments (five at this point) have used it and none had more than twenty programmers. Has it actually been an issue in real life?
Or FB sues you over literally any patent you happen to be infringing. They're a big company, I'm sure their patent war chest has a few zingers for cases like these.
Oh, and your scenario only works if you sue FB/Instagram over your patents first. They can't revoke the patent grant willy-nilly except in retaliation.
I should point out we don't even know whether Facebook even has any patents for anything React does. And even if they do we don't know whether there are other libraries that do the same things and therefore infringe on those patents, making you liable if you use them.
It's software patents you should be worried about, not open source projects that try to offer you even the tiniest amount of protection from them.
You mean unlike every company that is behind any other project you are relying on that doesn't come with an explicit patent grant?
In other words you have no MIT or BSD licensed dependencies, or in fact no open source dependencies that don't either come with an explicit non-revocable patent grant and aren't licensed under Apache 2.0, GPLv3 or MPL 2.0 (all of which by the way still terminate the patent grant if you sue over infringement of patents within the licensed code itself).
True, but it give Facebook more legal leverage over you, arguably, and Facebook is more likely to abuse that power than a loose collection of open-source programmers, or a smaller, less wealthy company that doesn't have its tendrils everywhere.
Barely anyone complaining about the patent grant seems to understand this point, so I'll reiterate:
The MIT license, the BSD licenses, and so on, don't contain a patent grant. Only the Apache 2.0, GPLv3 and MPL 2 licenses do.
If you use an open source project which doesn't come with a patent grant, you can be sued for patent infringement over that project.
Facebook's patent grant prohibits Facebook from suing you over patent infringement for using React, except if you sue them over patents first.
So nothing in your stance is specific to Facebook. If you use AngularJS, Google can sue you over any patents used in AngularJS.
Facebook's patent grant acts as a kind of "no first strike" policy they have to obey for React-related patents: they can't sue you over React-related patents unless you sue them first.
Yes, Facebook can still sue you over other patents. Everybody can do this, even if you don't use their software.
Is Facebook's patent grant as permissive as those in the Apache 2.0, MPL 2.0 and GPLv3 licenses? No -- these only allow retaliation if you sue over the projects the licenses cover specifically.
But the patent grant is considerably better than not having a patent grant. If React is covered by patents (nothing in the grant requires Facebook to actually own any relevant patents), it's extremely likely similar libraries are just as likely to be covered by them (without a patent grant from Facebook) and open you up for liability.
Patents are not specific to software. If something React does is covered by a patent and another project also does it, that's still covered by the patent even if the code isn't from React, even if the author wasn't even aware of React doing it and never heard of the patent.
So, yes, if you exclusively use GPLv3/Apache 2.0/MPL 2 licensed projects, you're safe -- except for all the other patents you might be infringing on that aren't owned by the maintainers (and that the maintainers therefore can't give you a patent grant for).
But there is no scenario whatsoever where using React opens you up to more patent woes than using an alternative implementation -- or a comparable project (like AngularJS, Ember, etc) that doesn't come with a patent grant.
If you're concerned about React, be concerned about AngularJS first. Because if you use AngularJS, Google can sue you over patents without having to wait for you to sue them first.
One of the first questions I would ask is what is an indirect assertion of a patent in this situation? If you get shaken down by a patent troll for a patent related to React stuff, would that be considered an indirect assertion? After all, you're making a statement there that React is violating some patent. While I can agree with patent severance clauses, this one just feels full of real ugliness that would drive a lawyer crazy.
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.
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/
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.
I have learned, from experience[†], that strongly and statically typed languages, and in general languages with rich type systems almost always result in fewer common bugs, and higher quality code.
I strongly believe statically typed language are objectively superior to dynamically typed ones. Many might say that this is my subjective opinion or just a matter of personal preference, but I absolutely disagree.
I would much, much rather use a modern, statically typed language than a dynamic language. This includes languages like Swift, Scala, Kotlin etc and specifically excludes Java.
I wouldn't even consider dealing with a big JS codebase without either Flow or Typescript now.
Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. JS has its uses, but it's difficult to debug, doesn't take advantage of all the advances in modern languages design that help prevent whole classes of bugs, and carries a lot of baggage. The only benefit would be universal app development, but even then Xamarin seems like a better choice.
>Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift.
Because targetting javascript has a lot of advantages, being cross platform is a major one of them. You basically get the type-safety of swift, with the ability to target multiple platforms.
The fact that it transpiles to JS is irrelevant, you can provide a safe interface to something unsafe. Take Elm for example, it transpiles to JS and yet guarantees that you will never produce a runtime exception.
> Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift.
The JavaScript toolchain is more than good enough to build the kinds of applications that React Native targets. Most of these applications aren't stellar apps that require critical performance or rigorous type checking, they're just dumb front-ends to REST endpoints. If you're going to build an awesome app, then use better tools.
The reason I would use React over Xamarin is simple: Speed of training and development. I can hire, train and get a React developer up and running and building proof-of-concepts a lot quicker than on Xamarin.
RN supports iOS, Windows, and Android. Plus RN is somewhat close to React, so some code could be reused between the two. Plus you get out-of-band code updates!
Xamarin supports iOS, Windows, and Android. But there is no web story. Or is there?
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.
TypeScript gives you the benefits of dynamic typing without the drawbacks of a C++/Java restrictive-typing system.
It just makes the dynamic typing safer. It absolutely should be considered a best practice; anything that can accelerate development by 100% or more should be.
Unless you are doing Java, I would even take issue with the argument that dynamic typing is faster to develop. It's taken as obvious fact but I don't think we should just take that as face value. Getting as-you-type feedback, intellisense, and simple documentation (methods, parameters, types) is hugely productive. As well as the ability to break things and know you've caught all the breaks.
I would say that a very fast edit-run cycle is an advantage of dynamic languages -- especially if you can edit code live without restarting the application -- but that's not always the norm.
I agree, and I consider TypeScript to be twice as fast to develop in as plain JavaScript just because you don't need to:
* Look up member names
* Look up object hierarchy structures
* Run code (or tests) to verify that you've done the above correctly
When the compiler knows the types, it can bring your code up to 90% correct. Half the time you don't even need to specify types: TypeScript can guess them from context.
You need to specify parameter types and return types; if you're declaring a variable without initializing it, or assigning it an empty array or object, you need to specify its type. Other than that you generally get type inference from TypeScript (at least as of 2.0).
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.
It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand.
I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]).
The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was.
In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo".
In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry.
In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things.
In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible.
The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors.
And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices.
That's an example of bad design. You can do that in Java as well, just in different ways. There are trade-offs that you make, and it means that various languages and type systems make different kinds of screw-ups easier.
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.
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.
Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.
If you are not building large applications then TS is counter productive. Just consider the extra compilation step, the dependencies and obfuscated source code.
While it can be tremendous help, calling it a best practice misses the point.
The code output is really clean; I wouldn't call it obfuscated. Especially when source mapping works just about everywhere.
And having ES2015 features (+async/await) is very useful: var should be deprecated, arrow functions should be standard, etc.
Tiny projects? Sure, do whatever you want. But I've started switching even my one-file, 2-3 screens of code Node servers over to TypeScript, and it's not only useful, it accelerates development by 100% simply because you don't need to run your code to know that you've got the types correct.
OP is not complaining about dynamic type -- the examples appear to show where 'type' doesn't apply at all.
The funniest/alarming example for me though was immutablility. The documentation exhorts the developer to take care not to make assignments to immutable objects. And there's your immutability: just don't change object and it will be immutable.
Alarming? Just use facebook's immutable types or a transpiled language (eg typescript) that has them built in. Unless you're meaning it's funny/alarming how the author was able to write so much without googling a solution..
Well then, if no true programmer likes dynamically typed languages, I'd better make some calls...
Hey, RMS, Abelson, Sussman, Steele, Guido, Larry, Matz, Richard Gabriel, ESR, DHH, Flatt, and Felleisen, it turns out you're not true programmers! Okay, cool.
All languages have types. Lisp, however, and particularly the versions that those people worked with, are dynamically typed, like Javascript. Unlike JS, they aren't weakly typed, but that's not the point. To say nothing of Ruby and Python, for which there are also programmers on that list.
Common Lisp compilers may implement static typing. The default type is T, though — but with declarations, a compiler can enforce anything the programmer declares or it infers.
Exactly. Flow even has tagged unions now, and `maybe` types. TypeScript is also a very mature solution to this problem. A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available.
In this case, I half agree, because I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must. And React is an elegant way to handle browser UI (Flow/Redux is also quite nice way to handle browser state, if a bit verbose).
I do share his concerns about the patent clause, and about Facebook's long-term commitment to the project, but at the level of personal projects, these concerns have not been enough to scare me away.
Since apparently people are missing my ':)' above, they are missing that I replied to what I thought was a joke with another joke. So just to be clear, it was a joke. Sigh.
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..
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?
When the stack trace is inscrutable, I find binary search debugging to be helpful. Comment out half of the functionality, see if the error is still there. Narrow the search to the half that is causing the problem, rinse, and repeat until the offending line of code is found.
However, if the error occurs inconsistently, this approach can be much harder to use.
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?
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.
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)
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
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.
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.
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.
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!
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.
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).
I have been using RN from 0.19 onwards never broke my app a single time. React encourages thinking in components and component would be tightly coupled. I have many kitkat users on my beta app on playstore. For me reactjs is way simpler. Angualr seems like a jee framework.
On the tooling I presume it is impossible to get help with the html markup, since it is commingled with code? Like there is no way to start writing html in your js function and for the IDE to autocomplete a class name based on the CSS it knows will be loaded on a page. This is sort of coding in notepad. Or are there tools that see through the js and understand how the whole page will fit together?
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).
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.
Titanium has always been a pretty advanced product however ever since Appcelerator introduced it's licensing/arrow stuff, Titanium (and Alloy) uptake seems to have fallen off a cliff.
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.
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.
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.
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
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
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...
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.
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.
"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."
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.
Yes. It is not difficult. There are typings files floating around. When you need to use something that's not in the typings file, spend 2 minutes updating it and keep going. Not a big deal at all.
NativeScript looks really promising. My colleagues have used it for numerous client apps. It's not as mature as Appcelerator Titanium so it doesn't have as many plugins for advanced things like video recording or audio playback but if it continues to get traction, it could become a really good option.
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.
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)
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/
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.
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).
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.
Objective-C also uses ARC by default, and that's been the case for several years now. In any event, avoiding retain cycles is relatively straightforward and most iOS devs I know would agree that the low memory overhead and lack of GC pauses are worth the occasional extra effort of weak references.
> 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?
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.
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.
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.
> 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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 .
He briefly mentions hot reloading and declarative UI at the start, but it's drowned out by his ranting on JS and doesn't seem to earn it any points in the end. But those two are huge boons for UI development, to the point where it's worth putting up with JS's flaws as a language. Flexbox and media queries make CSS pretty decent for layouts. Dynamic languages are a double-edged sword - for UI you often want something up and running and useable to see if it actually feels right, without worrying about interfaces and types too much. Objective-C and Java can feel clunky in comparison.
>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.
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?
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):
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.