都在封杀 React/React Native ,那我到底还该不该继续学呢?

时间: 2017-11-10阅读: 1479标签: 跨平台作者: loonggg

开源的世界真的很棒,技术的开源不仅仅促进的是社会的发展,有时还能看到一种精神,一种人性。当然,开源虽然并不意味着无私奉献,但是也不能暗藏玄机,或者暗度陈仓。真小人和伪君子还是有区别的。

最近在知乎上有一个帖子《如何看待百度要求内部全面停止使用 React / React Native?》,非常的火爆,以至于引发了前端的一片热议,整个圈子都在讨论这件事。很多人就在公众号后台开始问我:作为移动端的程序员,我还有必要学习 RN 技术吗?


事件由来

这件事之所以最近火爆起来了,是因为大家发现了 Facebook 专利许可证上的一段文字,里面暗藏玄机,导致很多企业,尤其是像 BAT 这样的互联网大企业人心惶惶,不得已终止或者放弃。

在技术开源的世界,对于开发者而言,许可证就是他们使用开源软件的 “用户协议”。而 Facebook 的开源方式跟其他家都不太一样,别家一般用的都是开源社区公认通用的许可证,而 Facebook 使用的是两个许可证,第一个是通用的 BSD 许可证,第二个是自己写的专利许可证 (patent grant)。

而开源社区在发现,Facebook 在 React 的专利许可证里 “偷跑” 了一堆让开发者恐慌和心寒的条款,如下:


这段文字到底是什么意思呢?意思就是:如果你向 Facebook 及其子公司和其他相关实体发起专利诉讼,或者对其他使用 React 的公司发起专利诉讼,或者如果 Facebook 主动起诉你,如果你以反诉应对的话,你使用 React 的许可证将自动终结。翻译成大白话就是:如果你觉得 Facebook 侵犯了你的知识产权,你不能起诉 Facebook,而且 Facebook 起诉你,你也不能反诉!因为在起诉的同时你的产品就完了,产品中不可以继续用 React 了

反正我 Facebook 作为世界级大公司发明创造的技术,你们的产品如果使用了,那么该产品的知识产权我们可以免费用,免费用,免费用,而且你们还不能够起诉我。

其实这种事情,从去年就在前端技术圈开吵,后来愈演愈烈,形势每况日下:开源社区在更多 Facebook 开源的热门项目中发现了相同的许可证模式和条款。开发者认为 Facebook 的这种许可证模式正在毒害社区,污染开源精神。


大公司为什么如此担心和终止使用呢?

据传不仅仅是百度要求内部全面停止使用 React / React Native,阿里巴巴内部的技术决策层也都支持弃用 React,要求不再使用。大公司其实比小公司更担心,更害怕,所以尽快停止使用该技术可以减少损失或者防止以后有所损失。

你可以想想:如果 BAT 这样的大公司做出来的产品很容易火爆而且引领潮流,而且一般都会推向世界,如果 Facebook 抄袭并做出了类似的产品,你不仅不能告他,你和他是竞品关系,他还有可能要求你的产品停止使用该技术。你产品的知识产权我可以免费用,这对于大公司来讲,将来损失太大了。大公司的法律意识比小的创业公司强,而且完善,现在停止使用该技术,是为了避免未来发生法律纠葛。

如果这描述的不够清楚的话,知乎上的答友“我做分布式系统”,如是这样说:

以百度为例,按照 React 目前协议,要想不让 Facebook 事实上免费大胆用自己人工智能、自动驾驶方面获颁的专利,唯一选择就是不让公司的前端用 React。这笔帐,真的不难算。


那小公司呢?

说实话,对于小公司而言危险系数就小多了,低多了。毕竟国内的小公司的产品,一是,没有那么火爆和有影响力;二是,小公司的产品一般只在国内用。Facebook 都没有办法入华,你担心个什么呢?从这两方面讲,对于小公司而言确实不必那么担心。

而且 Facebook 的这款协议是防御性的。条款存在只是为了保护自己的核心专利,抑制不必要的诉讼。话虽然这么说,但是具有垄断性或者话语权的人来说,难免会为了自己的强大,而去抑制强大的竞争对手。就像美国这样的超级大国来说,在世界各地挑事不就是为了抑制其强大的竞争对手的发展,而使自己保持超级大国的地位,拥有世界的话语权吗?弱小的国家他们一般都不会在意与关心的,强国,大国才是他们的目标。所以啊,对于大公司来讲,有可能威胁到 Facebook 的企业才会触发这项条款,而一般的小公司,他也不会放在心上。

对于小公司来讲,目前影响基本可以忽略,也没必要担心。


我,还学吗?

今天的话题就是这个,有人问:我还能继续学 RN 技术吗?说实话,技术的发展离不开大公司的贡献,也不离开程序员的支持。但是一个技术的火爆,需要大公司的引领,一旦 BAT 这样的大公司停止了使用 React 这项技术,自然就会引发很多人不再去学习 React 这项技术。在国内使用 React 技术的人可能会减少,减少,减少……

我感觉我们移动端的程序员没必要担心,即使 RN 很火爆的阶段,依然无法替代我们的原生开发,目前来说,我感觉学习 RN 不如学习后台,学习个 Python 对于大家来说更有用。当然,如果你所在的公司坚持使用 RN 技术,那么你学习也无所谓,所有的编程思想都是想通的,原理都差不多,多学一门技术也无妨。

但是,我相信如果一旦像百度和阿里巴巴这样的大公司停止使用该技术,那么国内很多程序员都会不再学习该技术,这应该没什么疑问。

目前能够代替 React 的语言和技术有很多,但是找到一个真正能够代替 RN 的却很难。


技术开源,产品无罪

这真的很 Facebook ,在开源的世界,得有开源的精神。不要以技术威胁别人家的产品。技术并不可耻,产品也是无罪的。Facebook 作为世界级的大公司,连点自信都没有吗?不要因为拥有者垄断性的地位,就拿技术去威胁甚至盗版,侵犯别人家的产品。技术开源,产品无罪。

而且Apache 软件基金会宣布所有使用 Apache 开源协议的软件都不得使用带有 Facebook BSD + 专利许可证模式的组件。连 WordPress 也决定换个技术重写 Gutenberg,这可能会导致项目进度变慢,明年才能发布,但是 WordPress 目标是没有任何专利问题,不会让专利风险被转嫁给我们的用户。

希望 Facebook 能够觉醒,更换许可证,还开源的世界一片净土和安静。

转载来源:非著名程序员

如何将React Native 项目运行在 Web 浏览器上面

React Native 的出现,让前端工程师拥有了使用 JavaScript 编写原生 APP 的能力。相比之前的 Web app 来说,对于性能和用户体验提升了非常多。但是 React Native 的代码只兼容两个平台(iOS 和 Android),并没有兼容 Web 端访问。于是 React web 就出现了

MobX在React Native 中的使用心得

MobX 是一款十分优秀的状态管理库,不但书写简洁还非常高效。当然这是我在使用之后才体会到的,当初试水上车的主要原因是响应式,考虑到可能会更符合 Vue 过来的思考方式。然而其实两者除了响应式以外并没有什么相似之处。

React-Native创建组件Component的三种方式

React-Native创建组件的三种方式:ES6创建组件的方式、ES5创建组件的方式、函数式。当创建的方式不同的时候,其实他们的导入方式也有几种。

React Native常用插件_整理React Native插件系列之插件汇总

感觉到React Native的写APP效率真的很高,在NPM上搜索了一些插件,发现React Native的生态圈现在真的很大。绝对可以满足现在很多APP的需求,而不止企业类的APP了。

Flutter框架_谷歌推出的跨平台打造ios和android高质量的原生UI框架

Fluter是由google一款移动UI框架,意在帮助开发者在 iOS 和 Android 两个平台开发高质量的原生应用,Flutter是免费和开源的,就像Android SDK一样,并且可以与现有代码一起使用。Flutter的主要吸引力在于iOS和Android的智能和快速移动开发。

详细介绍 Weex 的 JS Framework【转】

Weex 是一个既支持多个前端框架又能跨平台渲染的框架,JS Framework 介于前端框架和原生渲染引擎之间,处于承上启下的位置,也是跨框架跨平台的关键。无论你使用的是 Vue 还是 Rax,无论是渲染在 Android 还是 iOS,JS Framework 的代码都会运行到

来聊聊怎么写react-native上的样式吧【转】

在react-native上是怎么写样式的吧,和传统的web不一样的是,在react-native上面是没有css代码,不过得益于Yoga,我们可以在客户端上像写css一样的去书写我们的样式。

Weex 和 React Native的区别和比较

weex的思想是多个平台,只写一套代码,而react-native的思想是多个平台可以写多套代码,但其使用的是同一套语言框架。

RN混合开发,React Native与原生android和ios的交互通信

React-Native新版本(从原生发送消息到JS),Android/iOS原生模块给ReactNative发送事件,通知监听,通过DeviceEventEmitter,NativeEventEmitter通过原生应用通讯。