weex vs react-native
前言
weex的思想是多个平台，只写一套代码，而react-native的思想是多个平台可以写多套代码，但其使用的是同一套语言框架。
weex的目标在于抹平各个平台的差异性，从而简化应用开发。而react-native承认了各个平台之间的差异，退而求其次，在语言和框架层面对平台进行抽象，从方法论的角度去解决多平台开发的问题。
进一步浏览weex和react-native的代码之后，可以得出如下的公式。
weex = Vue.js + H5/Native
react-native = React + Native总的来说，其差异性如下表格所示。
| dimension | weex | react-native |
|---|---|---|
| js framework | Vue.js | React |
| principle | write once, run anywhere | learn once, write anywhere |
个人观点，weex和react-native最核心的区别就是这两个。然而就只这两个维度的同步，导致了weex和react-native完全不一样的发展方向。
Vue.js vs React
| 维度 | Vue.js | React |
|---|---|---|
| 定位 | UI框架 | UI框架 |
| 目标平台 | Web | 多平台 |
| 架构 | MVVM | React |
| 数据流 | 数据绑定 | 单向数据流动 |
| 组件系统 | 有 | 有 |
| 响应式 | 是 | 否 |
| 开发语言 | html/css/js | all in js |
| flexbox | 支持 | 支持 |
| 外围框架 | 能和其他js框架整合使用 | 能和其他js框架整合使用 |
| 渲染机制 | real DOM | Virtual DOM |
| 动画 | 支持 | 支持 |
| 级别 | 轻量级 | 重量级 |
weex vs react-native
| 维度 | weex | react-native |
|---|---|---|
| 思想 | write once, run anywhere | learn once, write anywhere |
| 试用场景 | 简单明了 | 难易双修 |
| 扩展 | 为了保证各平台的一致性，一次扩展得在各个平台都实现 | 不同平台可自由扩展 |
| 社区 | 内测开源 | 15年3月开源，社区非常活跃 |
| 支持 | alibaba支持 | facebook支持 |
| 组件丰富程度 | 基本只有自带的10余种 | 除了自带的，还有js.coach上社区贡献的，还是比较丰富的 |
| 上手难度 | 容易 | 困难 |
| 调式 | 暂时log调试 | 有专门的调试工具，chrome调试，较为完善 |
| IDE | 文本编辑器 | Nuclide/文本编辑器 |
Vue.js
Vue.js虽然是Evan You个人开发的开源项目，其社区活跃度以及代码质量还是值得一提的。在写此文章之际，Vue.js在Github上的Star达到了21099，Fork达到了2186。虽然相比于react的Star数44108，Fork数7610还有一定距离，但考虑到作为个人开发者能有如此多的人关注参与，该框架的优秀程度恐怕不会低于React。
Vue.js的文档资料非常齐全，而且其本身的设计非常简洁，因此绝大部分开发者只要花费少量的时间就能快速上手Vue.js。其中VUE.JS: A (RE)INTRODUCTION是 Vue.js的作者Evan You对Vue.js的介绍，非常值得一看。我想这可能也是weex团队选择Vue.js入手的原因之一吧。对Vue.js有兴趣的同学可以移步Vue.js Guide自行学习。
Vue.js用来构建交互式web界面的，其主要的关注点和React是一样的，都是立足于View层。
Vue.js最核心的部分是两个Reactive Data Binding以及Composable View Components。还值得特别关注的是，其保留了html、css、js分离的写法，使得现有的前端开发者在开发的时候能保持原有的习惯。
响应式数据绑定
Vue.js将界面开发分成了三个部分，分别是View、ViewModel和Model，这种划分在客户端开发看来是非常合理的，也经过了实际的检验。以HelloWorld为例来说明，示例来源Vue.js Guide。
<!-- this is our View -->
<div id="example-1">
Hello {{ name }}!
</div>
<!-- this is our Model -->
var exampleData = {
name: 'Vue.js'
}
<!-- this is our ViewModel -->
var exampleVM = new Vue({
el: '#example-1',
data: exampleData
})这就是经典的MVVM模式，Vue.js通过极简的API，将数据和视图绑定在一起，也就是所谓的Data-Binding。
这样，当数据变化的时候，界面就能变化，实现了数据驱动的响应式变成。
组件化
当我们在写网页的时候，本质上就是构造DOM树，DOM树则是由div、span等元素组成的。div、span这样的元素是构建大型应用的基础。其实Vue.js或者其他的UI框架基本也是一样的，他们都会提供自己的组件系统。这些组件就类似div元素，一般具有一下特征：
- 小巧精致
- 能重用
- 自包含，高内聚
当我们使用Vue.js开发应用的时候，就是搭建特定的组件树。这些组件可以是Vue.js定义的，也可以是开发者自己定义的，这非常重要。
看个组件化的例子。
// example组件定义
var Example = Vue.extend({
template: '<div>{{ message }}</div>',
data: function () {
return {
message: 'Hello Vue.js!'
}
}
})
// register it with the tag <example>
Vue.component('example', Example)
// example组件使用
<example></example>组件间数据传递
Vue.js的组件都是有自己独立的scope的，因此子组件是不能直接访问到父组件的数据的。数据一般都是通过props来传递的，示例说明。
// define component
Vue.component('child', {
// declare the props
props: ['msg'],
// the prop can be used inside templates, and will also
// be set as `this.msg`
template: '<span>{{ msg }}</span>'
})
// usage
<child msg="hello!"></child>上述方式只能实现组件树从上往下传递数据，在Vue.js中，会有大量的场景需要子组件向父组件传输数据，甚至兄弟组件之间传递数据，一般这种时候就需要使用以下几种能力。
- 子组件获取父组件的能力（
this.$parent） - 自定义事件的能力 (
$on, $emit, $dispatch, $broadcast)
想要了解详情，请移步Parent-Child Communication。
样式、逻辑和界面的分离
前端开发经过这么多年的发展，html、css和js的分开编写应当是顺理成章的，Vue.js没有打破这个规则，通过 style 、 template 、 script 将样式、视图和数据逻辑进行了分离。详见下面示例，来源于VUE.JS: A (RE)INTRODUCTION。
<!-- css -->
<style>
.message {
color: red;
}
</style>
<!-- template -->
<template>
<div class="message">{{ message }}</div>
</template>
<!-- js -->
<script>
export default {
props: ['message'],
created() {
console.log('MyComponent created!')
}
}
</script>React
React可能是现在前端开发中最炙手可热的UI框架了。在React的首页最明显的位置上展示者关于React的最核心的三个思想，它们分别是：
- Declarative(声明式)
- Component-Based（组件化）
- Learn Once, Write AnyWhere（一学多写）
声明式
React和Vue.js的组件的使用都是声明式的，声明式的编写方式会比命令式的编写更加的直观。关于声明式和命令式的区别，可以参考Declarative programming和Imperative programming，这里就不加详述了。
组件化
诚然React和Vue.js在编写大型程序的时候都是构建一颗组件树，但React和Vue.js的组件却有着不小的差异。先来看一个React组件的示例（来源React官网）。
var HelloMessage = React.createClass({
render: function() {
return <div style={divStyle}>Hello {this.props.name}</div>;
}
// style
var divStyle = {
color: 'white',
backgroundImage: 'url(' + imgUrl + ')',
WebkitTransition: 'all', // note the capital 'W' here
msTransition: 'all' // 'ms' is the only lowercase vendor prefix
};
});
ReactDOM.render(<HelloMessage name="John" />, mountNode);在React中，一切都是js，视图、逻辑和样式都是通过js来写的。通过js来统一颠覆了html、css和js分离的原则，当然是褒贬不一了。在Vue.js中，分离带来了清晰度，逻辑、视图、样式和数据可以分别处理，但在React中，一切都需要重新组织，甚至需要新的配套框架和设计模式，比如新的语言JSX就是用来简化js带来的麻烦的。但all in js让很多事情变得简单，js的快速发展也让React脱离了css和html发展限制，可以实现更多的可能性，优化、扩展以及其他很多事情，就只要单纯考虑js就可以了，而不必收到css和html的限制。
当然，这样带来的后果就是学习曲线的陡然增加，React甚至带来了新的JSX语法，同时考虑到React全新的React思想，开发者想要开发生产环境的app，尤其是在将现有app用React重写的时候，成本是要比Vue.js高出不止一个数量级的。
组件间数据传递
React推崇的是单向数据流动，也就是说，数据最好是从组件树的顶端往叶子节点流动，尽量少的出现反向流动的情况。
用另外一种方式来说，React希望实现的immutable data，数据的不变性。只读的数据能给我们带来非常多的好处，并发、简化逻辑、数据统一管理等等。
React提供了props和state两种数据类型，props是实现数据从父组件往子组件传递的机制，而state则是提供了一种机制来实现组件的自更新，facebook是建议尽量少用该特性，因为其违反了immutable data和单向数据流动的设定。
因为React的数据设定让其数据管理成为一个问题，业界出现了一些解决方案，其中最为著名的应该就是redux/flux了，有兴趣的同学可以上github搜搜，都是开源的。
一学多写
React背后是强大的facebook在开发维护，其目的不是要简单的创建一种新的js的UI框架，相反，其想要让React成为平台无感知的UI开发思想。什么意思呢？就是本节要说的learn once，write anywhere。facebook认为每个平台不可能完全一样，Web、Android、iOS、Windows Phone甚至Xbox，以及未来会出现的各种平台，他们都会有自己的发展理念和发展路劲，不可能做到完全一样，但不管平台如何变化，基于平台之上，创建Virtual DOM，React通过控制Virtual DOM来实现界面变化。
也就是说Virtual DOM相当于是一个中间层，隔离平台的差异，从而实现统一的开发方式。
不敢说这样的想法一定能成功，但就现在的发展势头来看，机会还是非常大的。尤其对于开发者来说极具吸引力，如果这一想法成为现实，以后React就可能像DOM一样成为业界统一的标准。那对于iOS开发者来说，在Android上面开发会跟在iOS上开发一样，不需要学习全新的Java语言，Android系统，更不要说各种Java特有的艰深复杂的工具了。
Native
个人感觉weex和react-native最大的不同是在Vue.js和React层面。这一点在react-native的命名上就非常容易看出来。在react-native刚出来的时候，其和React的关系是react-native依赖React。
"dependencies": {
"react": "~14.0.0"
}而现在react-native和react则是同级别的。
"peerDependencies": {
"react": "~15.1.0"
}react-native中最重要的文件名字也是Library，主要提供了一系列Native的能力。
查看weex的源码，native部分的作用几乎是一样的，主要就是提供了一些列Native的组件，以及其他的一些能力。
这也就是为什么本文将两者的Native合为一谈的原因，他们的本质是差不多的。
- 提供了js和native交互的桥梁Bridge
- 提供了一系列组件
- 提供了flexbox布局支持
- 提供了事件支持
- ……
当然，因为weex和react-native的设计思想的差异，在native部分也存在差异，但我觉得这是因为js需要导致的，仅就native而言，两者并没有特别大的不一样。
也许在不远的将来，native部分会出来一个比较核心的框架，抽象出在构建App时js和native交互所需要的基本能力，同时提供扩展方式，让各种类似react-nativeweex这样的框架可以专注于js层的设计。也许react-native就走在这条路上，谁知道呢？
展望
动态化的世界越来越精彩，对于weex和react-native的了解才刚刚入门，需要更多实操经验来深刻体会到两者的博大精深。weex和react-native各有千秋，开源的魅力也正是在此。