红尘梵音 发表于 2016年10月2日 05:30
Most of my experience is in native Android and iOS mobile development. Although I’ve typically been skeptical of cross-platform development tools for mobile, I think that react native is really neat. In fact, I’m willing to bet that its the future of mobile development.
您需要 登录 才可以下载或查看，没有帐号？立即注册
I disagree with Ariel Elkin, who recently wrote an excellent articlein which he explains why he thinks using react native is a bad idea. While several good points were made, I think that ultimately the argument he puts forth is lacking. In this article, I try to say where I think Ariel goes wrong in his arguments against react native.
React Native’s licensing isn’t Scary
In the section (cleverly) titled “Patently Daunting,” Ariel argues that by using React Native,
…I’m jeopardising…both the platform my app depends on as well as my intellectual property.
He then says that:
iOS apps enter the App Store entirely at Apple’s discretion. I don’t want to multiply that uneasy feeling by two.
There’s a comment on HNthat pretty well addresses this concern:
…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 [licensed used by projects like jQuery, Angular, and Ember], which have no patent provisions whatsoever.
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.
Organizations that use any of these open source packages do so because they believe that the advantages of using these packages outweigh the risk of getting sued for patent infringement. This seems like a reasonable assessment in general and, as we’ll see in the next sections, I think its a reasonable assessment for react native in particular.
Mobile developers have been a special snowflake in many companies hiring and development processes. We have our own skills with our own tools and our own languages. This costs businesses a lot of money. The ability for businesses to say, “Our web developers can now develop mobile applications” is a huge win. 1
Mobile developers have been writing almost exactly the same code for two different platforms for almost 8 years now. Businesses simply do not want to keep paying us to write the same code twice, especially now that the mobile app market is becoming saturated. 2
This is what our employers are thinking:
“You mean I can share up to 85% percent of my code across both platforms 3and I can have my web developers contribute to mobile apps and all I have to do is use an inferior programming language? Sign me up!”
Flow isn’t like Flossing
The first argument against flow has something to do with it being built on “weak foundations:”
Here’s the thing: all programming languages are built on an unsafe, unproductive foundation: binary. This fact doesn’t bother us because the abstractions and tools we’ve built on top of binary and assembly are good enough to allow us to be very productive.
There’s a second argument that Ariel offers against the usefulness of flow that’s pretty interesting:
There is another fundamental problem with these palliative measures [like flow and linters]. Safeguards, like laws, are worth very little if they’re not actually enforced by the authorities and respected by the community. Flow doesn’t stop you from building and running React Native apps with code bound to generate runtime crashes. And that is a basic safety requirement for a programming language: if it’s a preventable error, the language should actively prevent it, it should stop me from writing and running unsafe code by default, not as an afterthought.
A part of this seems right to me. All other things being equal, a language is better if by default it catches errors earlier on in the development cycle.
For better or worse, React Native is a good bet
I believe in react native so much, in fact, that I’m betting my business on it. Code Cookbook is a company that helps teams start using react native for their business. Sign up for our email list below for updates and online tutorials on react native or email me at chefmatt[that symbol that comes between a handle and a domain]codecookbook.coso we can chat about how I can help.
p.s. As you can tell from the obnoxious way I just published my email, I hate spam, so I won’t be spamming your inbox either.
- I’m not saying here that native mobile development expertise isn’t (at this point) necessary for being an effective react native mobile developer.
- For evidence of the saturation of the app market, take a look at slides 11 and 12 of this past year’s internet trends report.
- Facebook was able to achieve 85% code reused for their conference app.
上一篇：Graph Convolutional Networks – An introduction to neural networks on graphs
下一篇：Rust gets working asmjs and wasm targets