While there are some valid concerns with using React Native, the productivity gain and community make it a more than worthwhile trade off.
Indeed this would be nice to have!
- No guarantees from Facebook about longevity
As more products within Facebook (eg: Instagram) and companies outside of Facebook are depending on this (Airbnb, Netflix, Alibaba, Microsoft, Baidu, Uber), there is a bigger community of folks who share the burden of keeping it going.
- Legal concerns
This is the same license as React. Given the breadth of companies depending on React (all of those mentioned above, plus thousands more), I suspect that their legal departments considered it to be acceptable. If you don't, that's certainly fine!
- JavaScript problems
JavaScript does have plenty of problems, but it's also what enables a lot of the nice things about React Native (x-platform, ota updates, resource sharing -- as the author identified).
- Alternate frameworks: Xamarin, Appcelerator
I'd like to see the author write a similar assessment of these tools! It's worth noting that the author seemed to be unaware of the existence of React Native for UWP, maybe that would alter his assessment.
var weAreConnected = Math.floor(Math.random() * 10) > 5
if (weAreConnected === true) {
this.setState({
isConnected: true
})
}
else {
this.setState({
isConnected: false
})
}
Instead, simplify the logic var weAreConnected = Math.floor(Math.random() * 10) > 5
this.setState({
isConnected: weAreConnected
})
The random choice is also overy complicate (and on a side node, the value is more likely to be false then true due incorrect comparision operator usage) var weAreConnected = Math.random() < 0.5
this.setState({
isConnected: weAreConnected
})
If we use ES6, we can use the shorthand notation to simplify the code even more const isConnected = Math.random() < 0.5
this.setState({
isConnected
})I've noticed a pattern in "X vs. Y" articles where the examples of the technology the author doesn't favor are unnecessarily complex.
That said, I think every JS feels these pressures internally. In 2015, some were even brave enough to give it a name — "JavaScript Fatigue". I personally work with TypeScript. But each time you kickoff a new project these days, the task of getting past all the boilerplate work seems to be increasingly difficult.
On the point of community versus big company support I can't help but observe what appears to be anti open source sentiment conveyed as fact. While many of us have seen fads come and go we have to admit the wild success and stability of many open source libraries without formal agreements to maintain them. Everything from Rails, to Django, to jQuery, and Linux distros. There is a caveat here that JS libs do seem to die out faster and have questionable quality but again plenty are also great.
I think the choice of React Native really boils down to understanding the platform and source. If you understand how React Native leverages the toolkits and interacts with the system I think you have the tools you need to make a good decision.
For me I prefer native development where I can easily control and limit dependencies. If I want to hit all devices or most I'll build a great responsive web app. At the end React Native is today NOT a production level solution that will cover android and iPhone devices, android is a separate toolkit.
My rambling is done I suppose. If anything can be gleaned from this it is to understand the risks and be mindful of the costs of adopting a new framework and dev environment. If you are careful, intentional, and lean on smart teammates for help you will be just fine.
And the recommendation at the end for Flutter, which shares all attributes of RN (open source, free, cross platform, from a large tech company, but one known for killing projects), was strange. It made the argument essentially I want RN but not a dynamically typed language.
The whole native widgets thing gave reminds me of GWT/AWT too, we're going around in circles.