小而美Vue.js的初体验

这几天一直在捣鼓小而美的Vue.js，这篇文章查阅了网上的一些资料（见文末的“参考资料”），对比React和Vue各自的优缺点，然后结合自己的一些思考，对Vue.js做一个简单的回顾和小结。

为什么选择Vue.js？

• 业务场景偏重于表格和表单（例如控制台），这种情况下前端的模型之间的关联很少，并不很需要组件化，而且各个组件之间的通信也很简单。
• 希望能兼顾重型应用和轻型应用。
• 追求性能且应用尽可能地小（例如移动端的情况），这里需要指出的是Vue 2.0做的非常精简，加上控制路由的Vue-router后也只有26kb，作为对比，用React实现同样的功能，需React DOM（37.4KB）和React with Addon库（11.4KB），共计44.8KB，几乎是Vue的两倍大。
  
• 喜欢使用模板来写应用，这一点从Angular过来的开发者会非常容易上手。模板相对于JSX来说，能更直观地思考语义结构，更好地结合CSS进行书写。
  
• 对浏览器的兼容性没有太多要求（IE9+），话说淘宝都宣布不支持IE8了，所以就放心大胆地用吧。
• ……..

渐进式的前端框架

在实际的开发过程中，我们要解决的问题是不尽相同的。

• 我们可能需要组件系统，从而将一个大型的界面切分成一个一个更小的可控单元；
• 我们可能需要做单页应用，那么就需要有一个URL对应到一个应用的状态，从而我们需要有一个客户端路由解决方案；
• 我们迫切地需要声明式的渲染功能，并希望尽可能避免手动操作（可变的命令式操作），希望尽可能地让DOM的更新操作是自动的，状态变化的时候它就应该自动更新到正确的状态；
• 我们可能需要大规模的状态管理。因为在开发一个多人协作的大型应用时，会涉及多个组件之间的共享、多个组件改动同一份状态等各种情况，且这样的大规模应用要能够高效运行。
• 我们要有自己所偏好的构建工具
• …….
  

我们可以选择大而全的前端框架（例如Angular、Meteor），但是这样以来，灵活性就变低了，同时这样的大型框架学习成本也会更高，所以针对这个问题，React和Vue有一个共同的特点，它们都有各自的配套工具，核心虽然只解决一个很小的问题（React自身仅仅针对View这一层），但它们有生态圈及配套的可选工具（Vue-router、Vuex、Redux、Flux），当我们把他们一个一个加进来的时候，就可以组合成非常强大的栈，就可以涵盖其他的这些更完整的框架所涵盖的问题。

所以Vue的一个重要思想是：核心+生态工具的前端技术栈是一个在整体上选型更为灵活的栈。

Vue的设计

这其中，声明式渲染和组件是Vue自带的，而客户端路由、大规模状态和构建工具是可选的。下面重点讲讲声明式渲染。

首先，DOM应尽可能是一个函数式到状态的映射。状态即是唯一的真相，而DOM状态只是数据状态的一个映射。所有的逻辑尽可能在状态的层面去进行，当状态改变的时候，View应该是在框架帮助下自动更新到合理的状态，而不是说当你观测到数据变化之后手动选择一个元素，再去改动它的属性。

在Vue2.0中，渲染层的实现做了根本性改动，引入了Virtual DOM。Virtual DOM的算法的实现过程可以简单地这样描述：

• 用JS对象模拟DOM树，生成一颗新的Virtual DOM后
• 比较两棵虚拟DOM树的差异，进行diff，得到一个补丁patch
• 把差异应用到真正的DOM树上

以实际开发中的一个简单例子来解释：若我们需要在 ul 元素中添加 li ，有的人的做法可能是for循环操作三次DOM并添加 li ，但在有了Virtual DOM后，框架可能就会先把三个 li 添加到新建的DocumentFragment中，然后整个进行render，这样会减小DOM操作从而提升性能。这一小段是我自己的理解，可能存在不准确的地方，但基本差不了太多。

具体来说，Vue的编译器在编译模板之后，会把这些模板编译成一个渲染函数，而函数被调用的时候就会渲染并且返回一个虚拟DOM的树。这个树非常轻量，它的职责就是描述当前界面所应处的状态。当我们有了这个虚拟的树之后，再交给一个patch函数，负责把这些虚拟DOM真正施加到真实的DOM上。

在这个过程中，Vue有自身的响应式系统来侦测在渲染过程中所依赖到的数据来源。在渲染过程中，侦测到的数据来源之后，就可以精确感知数据源的变动。到时候就可以根据需要重新进行渲染。当重新进行渲染之后，会生成一个新的树，将新树与旧树进行对比，就可以最终得出应施加到真实DOM上的改动。最后再通过patch函数施加改动。这样由框架/库帮你一次把整个DOM的最终状态映射出来，中间过程全部舍弃，会得到性能上的提升。

这样做的主要原因是，在浏览器当中，JavaScript的运算在现代的引擎中非常快，但DOM本身是非常缓慢的东西。当你调用原生DOM API的时候，浏览器需要在JavaScript引擎的语境下去接触原生的DOM，这个过程有相当的性能损耗。所以，更好的考量是把耗费时间的操作尽量放在纯粹的计算中去做，保证最后计算出来的需要实际接触真实DOM的操作是最少的。

参考资料

http://www.infoq.com/cn/articles/vue-2-progressive-front-end-solution
http://www.zcfy.cc/article/react-or-vue-which-javascript-ui-library-should-you-be-using-2159.html
https://www.zhihu.com/question/40195289
https://cn.vuejs.org/v2/guide/comparison.html