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