摘要：最终选择了兼容到的，终于使用上框架，虽然它只是个。没有对比就没有伤害本来想着技术栈统一，移动端也准备使用。于是，之后对移动端的技术选型上更加慎重了，最终采用了文档更漂亮的。易用还真不易用，坑还真多。
吐槽 avalon.js 历史背景
需求重大调整，所有业务推倒重来（pc端主要任务涉及管理后台类型的网站）；
开发周期很紧，过年前要上线；
公司pc端业务要求兼容到ie8；
2015年前端工资猛涨（特别是p2p这块），离职潮加剧，前来面试的要么不合适（99%的面试者技术水平对不起那份高工资，也许是我要求太高），合适的人没有选择我们，最后只剩下2个人，一个做业务逻辑，一个做页面重构；
开发周期很紧，过年前要上线；
我刚入职不久，之前的前端团队没留下什么现成的代码或模式，几乎所有的东西都需要重新开发。
技术选型在这种情况下，为了更快的开展业务，花了两三天时间，对技术选型做了一次任性而粗暴的预研：
抛弃了jquery这种基于dom操作的开发模式，后台有大量的数据交互和绑定，开发起来比较慢，维护性不高。因为ui都是完全自主，像easyui这类很重的框架一方面定制起来比较繁琐，而且学习成本高，最重要的是个人不是很喜欢。
而当下最流行的mvvm框架，像ng，vue，react都有一个致命问题--兼容性，虽然ng，react早期版本兼容ie8，当考虑以后的维护升级，就没有考虑。
最终选择了兼容到ie6的avalon.js，终于使用上mvvm框架，虽然它只是个vm。
对比过1.5和之前版本，本着对作者的大名的神往及信任，项目使用了v1.5这个版本，为后来的开发买下伏笔。
本来想着技术栈统一，移动端也准备使用avalon.js。由于一些需求和开发优先级等原因，迟迟没有开始。
前期粗暴的预研，渐渐在pc端业务开发到了中期，一直在chrome上做开发，回头做ie兼容性时，却踩了史上最严重的坑。
于是，之后对移动端的技术选型上更加慎重了，最终采用了文档更漂亮的vuejs。虽然说是慎重之选，其实更是一个幸运之选。
两个库我都在项目中使用，对vue越来越喜欢，而avalon越用越多槽点。
issue回复草率，bug坑死人，胡乱报错像这个issue，我想知其所以然。
虽然我通过用vuejs同理可知是因为涉及生成虚拟dom，组件模版必须有唯一的根元素。
这算我要求太高了，作者没有那么多精力，那么接下来的有点难忍了。
avalon 在v1.5中居然不兼容ie8-，包括官方的例子。
同样v2.0也是这样，自己写个教程，给的例子自己都不测试下。
他回复 issue的原话如下：
ms-modal关闭不了自己改改，那个本来就是教程！
太不负责了吧！如果连兼容--avalon的最重要的最基础一点都没做到，那我就没有使用他的必要了。
至于报错这项，比如父组件传值给子组件一个子组件未定义过的值，它居然这样报错
TypeError: 对象不支持此属性或方法 onInit
那onInit是什么鬼？
组件vue中有一个局部组件的概念，起初不明白为什么要那么设计。后来慢慢发现，这个设计太重要了，特别是在把某一个组件太过复杂，把他拆分成更小的组件时，把这些更小的组件作为一个局部组件封装在父组件内部，而不会被暴露到外部。
反观avalon的组件系统，内层组件会把所有外层容器的属性都继承下来，而且组件一旦定义就是全局的了。而且组件的属性没有却分内部属性和外部属性，没有了私有属性和方法的概念，全部能被外部传值给覆盖。
语法糖对一些语法包装上不是很友好，比如他写的教程
有一次调试ie兼容终性时，终于明白他为什么要这么写，因为在ie8-中，this[cbName]被包裹了一层函数，所有在ie8-下，必须执行两次，如下
this[cbName]() // 非ie8- this[cbName]().call(this) // ie8-
当然，或许是我使用的姿势不对。
对ms-if的设计很糟糕，对ms-if内部的语法限制颇多。比如：教程中提到的
注意,有许多人喜欢用ms-if做非空处理,这是不对的,因此ms-if只是决定它是否插入DOM树与否,ms-if里面的 ms-指令还是会执行.
正确的做法是,当你知道这里面有非空判定,需要用方法包起来
avalon.define({
$id: "test",
aaa: {},
show: function(aaa, bbb, ccc){
var obj = aaa[bbb]
if(obj){
return obj[ccc]
}
return ""
}
})
{{@show(@aaa, "bbb", "ccc")}}
我有大量的数据，那不是要写很多？如果ms-if里面还包着ms-if呢，写大量的这样丑陋的代码，太不人道了吧。到目前为止v2.1.14还存在大量的bug，比如组件中（非组件场景没注意）ms-if嵌套ms-for在ie8-不执行。
文档可能因为vue的作者设计出身，相比之下，vuejs的文档设计的相当漂亮。
且不说vue支持多种语言（好像中文文档是社区提供的），avalon的教程中充斥这大量的口语话的表达，这点尚且可以忍。
作为一份教程，avalon没有很好的把使用用法，注意事项清晰系统的表述，给出的例子七零八落，甚至还夹杂着bug。
作为一份api文档，v1.5中只给出寥寥几个api接口，以及一些简单的说明；v2.0有所进步，但是连基本的完整性都没做到，比如组件的api就没有罗列。可能他想解释：“你去看教程啊，里面有写啊！”
项目推广avalon 和国内很多开源库一样，没有做好推广工作，当然不是简单的拉来一堆人来助威，建个QQ群这样的堆人模式。
之前加过很多相关技术群，感觉聊天的模式解决问题太没效率了，不如在github上看issue提issue或者看源码。
相比之下vue的作者在这方面更善于经营。
黑魔法的坑定义组件时用wbr标签兼容低版本ie，用html-minifer压缩代码时遇到一个问题
