技术 | Hybrid载体的变化（三）
如图：惊讶的变化
前面两篇文章从客户端的两个角度来说了说变化，今天我们从前端的角度来看一看这些变化，对于我们的工作会有什么样的改变，记得在2013年下半年时在携程做Hybrid App，当时对于前端的选择很有限，最好的解决方案也只是require.js + zepto.js + backbone.js，而今天，特别是VirtualDOM的出现让Hybrid最终的呈现将不止于Web，有了UIView这种Native的Render Engine，或者类似小程序这样，严格分离的Web Render Engine，这些火花的碰撞，正是因为前端技术方案的变化而引起的。
模块化是前端工程化的一块非常重要的基石，而工程化的出现意味着你的应用可以在“可维护性”，“多态复杂场景”下达到一个最优的平衡，以前我们在写一个Hybrid页面时可能是这样的：
define(['baseView'],function(baseView){
return baseView({ })
})而现今：
import baseView from 'baseView.js';
class indexPage extends baseView{}
export default indexPage从直观上代码更易读，侧面来说可维护性达到了空前的高度。当然现在不一定是要baseView，你也可以通过一些方式去写一些基类，就像“UIViewController”一样有一些比较通用的方法，来处理“导航栏”的设置，转场等等。将这些比较通用的地方交给框架来处理，会降低业务编写的成本。带来这一切要从webpack，babel的普及，让我们可以从一个更易读的方式来书写JavaScript代码，这些构建上的变化改变了我们思考的方式，如今我们会更倾向用“package.json”来维护项目，因为npm提供了强大的脚本钩子来让我们执行我们编写的构建脚本。
Facebook在2014年的时候开源了一个前端库“React”，说实话当年它一出来我们就在思考这样的方式可以对Hybrid这样的模式带来什么变化，它总结了视图处理的方式，当然我们并不能去“狭义”的比较，当然一句document.xxx操作DOM的方式在只有改变一个值的情况下的意义，这样的类比以前讨论的很多，这样的比较毫无意义，但是为什么“它”敢说它比操作DOM要快？那是因为一个页面不仅仅只有一个DOM，当你全部重绘，肯定要比绘制一部分要慢，而“React”要解决的就是绘制一部分。很多年前Backbone也提供了数据变化而更新视图的功能，你可以用发布订阅模式来处理这一部分，但是你还是需要去手动的操作DOM的更新，比如当你使用backbone配套的jQuery时：
this.$el.html('<div></div>')这一部分传统意义上是可以交给框架去处理的，在“React”出现之前，“Angularjs”接替了一部分这些工作，那我们为什么要着重去说“React”呢？因为VirtualDOM这种来表现视图的描述，它为跨平台提供了基础和可能，这是AN无法比拟的。VirtualDOM将视图通过通用的结构来描述，比如：
{
tagName: "div",
children: [
{
"props": {
"className":"xxx",
"tagName":"div"
}
}
]
}对于Web的意义它描述的是一组DOM节点以及节点上应该有的属性，如果对它进行一定的扩展，理论上它可以描述任何可以绘制的界面，你需要实现的只是对应的Render Engine而已。这也正是为什么React会存在ReactDOM这样的一个模块，它就是Web 的Render Engine，用来绘制Web界面。那么，如果我们在Native端也实现一个NativeReactDOM这样的Render Engine，这也意味着你可以用UIView这样Native的UI来描述界面，这也正是在后期出现的React Native的原因，没有VirtualDOM这一层抽象的描述，你很难做到一个真正意义的跨平台。如果有心的朋友应该可以发现Facebook又开源了一个库叫ReactVR，这也正是利用了VirtualDOM的抽象描述，在对应的VR上实现Render Engine来达到的其目的。Hybrid模式的出现也是想利用Web技术来写移动App，但是它不是完美的一种解决方案，真正没有瑕疵的跨平台，还真要感谢VirtualDOM的出现。
说到了描述界面，我们应该还要关注一种CSS的布局方式，我们知道传统的网页布局float或者postions，特别是前者在移动端上的实现会比较蛋疼，后来为了简化布局，CSS技术上出现了一种叫Flex布局的方案，这个方案就非常容易来描述移动端上的实现，Facebook又提供了一个库来实现移动端的Flex布局叫yogo（https://github.com/facebook/yoga），当然还有css（https://github.com/reworkcss/css）将css转换成了JSON对象形式，有了这些，剩下需要做的就是通信了，看来我们又可以回到前面两章中提及了JavaScriptCore，它来沟通Native和JavaScript，将一个Native界面完完整整的绘制了出来。
其实又不得不提到另外一种思考：“transformer”，babel的出现将ES6转换成了AST，通过操作AST又可以将代码转换成ES5，它可以直接跑在不支持ES6的浏览器中。“transformer”也就是转换的一种实现，它来具体的操作AST，将代码转换成你想要的，这个的意义是在“编写”上的，如果一个技术很难书写，对于普及是有很大限制的，为什么React可以如此流行，那是因为JSX的一种语法定义，我们可以用HTML的方式来描述React，这种方式又称之为“DSL”，我们可以定义一组通用的标签来描述，在“transformer”的帮助下将它转换成JS可以执行的描述。
当你在描述：
<div className="icepy"></div>你得到的却是：
React.createElement('div',{ className: 'icepy'})甚至将你的CSS也进一步转换成对象，比如：
{
fontSize: '12px'
}有了这些，你在对应的地方实现Render Engine，就可以将一个界面绘制出来，想想，为什么会出现React Native，Weex这样的移动UI框架的原因，就在于此了。
你身边如果有朋友对混合领域（跨技术栈）或全栈，编程感悟感兴趣，可以转发给他们看哦，^_^先谢过啦。