資訊專欄INFORMATION COLUMN
摘要：最終選擇了兼容到的，終于使用上框架，雖然它只是個。沒有對比就沒有傷害本來想著技術(shù)棧統(tǒng)一，移動端也準備使用。于是，之后對移動端的技術(shù)選型上更加慎重了，最終采用了文檔更漂亮的。易用還真不易用，坑還真多。
吐槽 avalon.js 歷史背景
需求重大調(diào)整，所有業(yè)務(wù)推倒重來（pc端主要任務(wù)涉及管理后臺類型的網(wǎng)站）；
開發(fā)周期很緊，過年前要上線；
公司pc端業(yè)務(wù)要求兼容到ie8；
2015年前端工資猛漲（特別是p2p這塊），離職潮加劇，前來面試的要么不合適（99%的面試者技術(shù)水平對不起那份高工資，也許是我要求太高），合適的人沒有選擇我們，最后只剩下2個人，一個做業(yè)務(wù)邏輯，一個做頁面重構(gòu)；
開發(fā)周期很緊，過年前要上線；
我剛?cè)肼毑痪茫暗那岸藞F隊沒留下什么現(xiàn)成的代碼或模式，幾乎所有的東西都需要重新開發(fā)。
技術(shù)選型在這種情況下，為了更快的開展業(yè)務(wù)，花了兩三天時間，對技術(shù)選型做了一次任性而粗暴的預研：
拋棄了jquery這種基于dom操作的開發(fā)模式，后臺有大量的數(shù)據(jù)交互和綁定，開發(fā)起來比較慢，維護性不高。因為ui都是完全自主，像easyui這類很重的框架一方面定制起來比較繁瑣，而且學習成本高，最重要的是個人不是很喜歡。
而當下最流行的mvvm框架，像ng，vue，react都有一個致命問題--兼容性，雖然ng，react早期版本兼容ie8，當考慮以后的維護升級，就沒有考慮。
最終選擇了兼容到ie6的avalon.js，終于使用上mvvm框架，雖然它只是個vm。
對比過1.5和之前版本，本著對作者的大名的神往及信任，項目使用了v1.5這個版本，為后來的開發(fā)買下伏筆。
本來想著技術(shù)棧統(tǒng)一，移動端也準備使用avalon.js。由于一些需求和開發(fā)優(yōu)先級等原因，遲遲沒有開始。
前期粗暴的預研，漸漸在pc端業(yè)務(wù)開發(fā)到了中期，一直在chrome上做開發(fā)，回頭做ie兼容性時，卻踩了史上最嚴重的坑。
于是，之后對移動端的技術(shù)選型上更加慎重了，最終采用了文檔更漂亮的vuejs。雖然說是慎重之選，其實更是一個幸運之選。
兩個庫我都在項目中使用，對vue越來越喜歡，而avalon越用越多槽點。
issue回復草率，bug坑死人，胡亂報錯像這個issue，我想知其所以然。
雖然我通過用vuejs同理可知是因為涉及生成虛擬dom，組件模版必須有唯一的根元素。
這算我要求太高了，作者沒有那么多精力，那么接下來的有點難忍了。
avalon 在v1.5中居然不兼容ie8-，包括官方的例子。
同樣v2.0也是這樣，自己寫個教程，給的例子自己都不測試下。
他回復 issue的原話如下：
ms-modal關(guān)閉不了自己改改，那個本來就是教程！
太不負責了吧！如果連兼容--avalon的最重要的最基礎(chǔ)一點都沒做到，那我就沒有使用他的必要了。
至于報錯這項，比如父組件傳值給子組件一個子組件未定義過的值，它居然這樣報錯
TypeError: 對象不支持此屬性或方法 onInit
那onInit是什么鬼？
組件vue中有一個局部組件的概念，起初不明白為什么要那么設(shè)計。后來慢慢發(fā)現(xiàn)，這個設(shè)計太重要了，特別是在把某一個組件太過復雜，把他拆分成更小的組件時，把這些更小的組件作為一個局部組件封裝在父組件內(nèi)部，而不會被暴露到外部。
反觀avalon的組件系統(tǒng)，內(nèi)層組件會把所有外層容器的屬性都繼承下來，而且組件一旦定義就是全局的了。而且組件的屬性沒有卻分內(nèi)部屬性和外部屬性，沒有了私有屬性和方法的概念，全部能被外部傳值給覆蓋。
語法糖對一些語法包裝上不是很友好，比如他寫的教程
有一次調(diào)試ie兼容終性時，終于明白他為什么要這么寫，因為在ie8-中，this[cbName]被包裹了一層函數(shù)，所有在ie8-下，必須執(zhí)行兩次，如下
this[cbName]() // 非ie8- this[cbName]().call(this) // ie8-
當然，或許是我使用的姿勢不對。
對ms-if的設(shè)計很糟糕，對ms-if內(nèi)部的語法限制頗多。比如：教程中提到的
注意,有許多人喜歡用ms-if做非空處理,這是不對的,因此ms-if只是決定它是否插入DOM樹與否,ms-if里面的 ms-指令還是會執(zhí)行.
正確的做法是,當你知道這里面有非空判定,需要用方法包起來
avalon.define({
$id: "test",
aaa: {},
show: function(aaa, bbb, ccc){
var obj = aaa[bbb]
if(obj){
return obj[ccc]
}
return ""
}
})
{{@show(@aaa, "bbb", "ccc")}}
我有大量的數(shù)據(jù)，那不是要寫很多？如果ms-if里面還包著ms-if呢，寫大量的這樣丑陋的代碼，太不人道了吧。到目前為止v2.1.14還存在大量的bug，比如組件中（非組件場景沒注意）ms-if嵌套ms-for在ie8-不執(zhí)行。
文檔可能因為vue的作者設(shè)計出身，相比之下，vuejs的文檔設(shè)計的相當漂亮。
且不說vue支持多種語言（好像中文文檔是社區(qū)提供的），avalon的教程中充斥這大量的口語話的表達，這點尚且可以忍。
作為一份教程，avalon沒有很好的把使用用法，注意事項清晰系統(tǒng)的表述，給出的例子七零八落，甚至還夾雜著bug。
作為一份api文檔，v1.5中只給出寥寥幾個api接口，以及一些簡單的說明；v2.0有所進步，但是連基本的完整性都沒做到，比如組件的api就沒有羅列?？赡芩虢忉專骸澳闳タ唇坛贪?，里面有寫?。 ?/p> 項目推廣
avalon 和國內(nèi)很多開源庫一樣，沒有做好推廣工作，當然不是簡單的拉來一堆人來助威，建個QQ群這樣的堆人模式。
之前加過很多相關(guān)技術(shù)群，感覺聊天的模式解決問題太沒效率了，不如在github上看issue提issue或者看源碼。
相比之下vue的作者在這方面更善于經(jīng)營。
黑魔法的坑定義組件時用wbr標簽兼容低版本ie，用html-minifer壓縮代碼時遇到一個問題
