这篇文章是在 React Native 发布之前写的,已经过时了.@H_502_1@ 如果想了解推荐下面几个链接:
- 官网 http://facebook.github.io/react-native/
- 中文文档翻译 https://github.com/reactjs-cn/react-native
- 中文社区导航 http://nav.react-china.org/
不知道上下文的同学可以扫一眼 CSDN 上的介绍:@H_502_1@http://www.csdn.net/article/2015-01-29/2823762-facebook-announces-reac...
React Conf 的视频在这里:@H_502_1@http://react-china.org/t/guan-yu-react-native-xian-zai-de-xin-xi/241
原文是 Hacker News 上的帖子,我做了很粗糙的翻译,其中内容对视频做一些补充:@H_502_1@https://news.ycombinator.com/item?id=8964935
明天第二天的大会当中发布具体的信息之间,这篇翻译的内容也许有不准,请参考英文跟进
我是 Jordan 我在 React 团队(也是 React Native 团队). 这个线索已经有一些很棒的问题和看法了.@H_502_1@ React Native 围绕着生产力(当然还有能够使用 React 这套放弃)提供了大量的方便,@H_502_1@ 不过因为有很多关于性能的问题,我想我还是分享一些我个人关于它的看法.
React Native 和其他的方案区别很大,由于:
我们并不是希望给你一个神奇的戏法能让在你不改变任何的开发哲学/习惯的情况下就能自动生成出很棒的移动应用体验.@H_502_1@ 如果你在做移动开发,你想要很棒的用户体验. 你必需是要关心性能,必须关心怎么编写精细的交互.@H_502_1@ 任何优秀的移动端体验后面,都需要很专心的人. 不要相信别的说法.@H_502_1@ 不过,我感到相比而言要达到那样有些的效果,React Native 要求开发开发者做的工作,比其他我见过的备选方案要做的工作要少得多.
React Native 完全不用 DOM. React 原本用来解决浏览器开发中出现的,不可预测的编程实践当中常见的性能问题,@H_502_1@ 但是也仅仅能帮你做那么多而已.@H_502_1@ React Native 提升了一个层次,不止于浏览器所能做的.@H_502_1@ React Native 展示的 ReactJS 总是更多地偏向于 "zero DOM" 而不是 "virtual DOM"(跟大家以为的相反).
React Native 也很特别,因为我们想要继承一些 Web 开发当中好的地方.@H_502_1@ 这是因为我们只是想要性能,想要 Native View 的资源的控制能力,而不是要抛弃 Web 开发优秀的内容.@H_502_1@ 在 React Native 当中,你可是使用 CSS FlexBox 对 Native View 进行布局,@H_502_1@ 同时有很多很熟悉的样式属性,但是不会有泛滥的 CSS style reflow.@H_502_1@ 事件系统也跟现在 React 应用当中的一致,因为类库的代码是一样的.@H_502_1@ 按照 Web 开发中让我们高效开发的样式/布局的子集来构建应用,@H_502_1@ 那样开发者就能在当下就构建优秀的 Web 应用,而不是把时间排到未来.@H_502_1@ 我认为真的,相比鼓励开发者抛弃任何哪怕有点像 Web 技术的东西然后学一门完全不同的工具链(甚至两门三门),这样要好得多.
React Native 特殊的地方还在于它可以用 JavaScript 来写高质量的应用.@H_502_1@ 在浏览器当中,你很可能要对付一些低层级的限制,然后你没有办法.@H_502_1@ 或者是不能访问平台上的控件(在 scroll view 当中包含 physics/Maps),@H_502_1@ 或者是你在实现当中总是被图片解码干扰,没什么办法.
用 React Native 的话,你可以有一些办法了.@H_502_1@ 你可以在 ReactJS 应用当中使用那些永远不会用 JS 来实现的 view(比如地图),@H_502_1@ 而且你的构建当中可以用一些更高的执行粒度的 block,@H_502_1@ (多线程解码的 <Image />)(不使用 DOM 的 <View > block) 结果是这带来了质量方面到了空前的层次的感觉,而且对应平台的特征.
