摘要：最終選擇了兼容到的，終于使用上框架，雖然它只是個(gè)。沒有對(duì)比就沒有傷害本來想著技術(shù)棧統(tǒng)一，移動(dòng)端也準(zhǔn)備使用。于是，之后對(duì)移動(dòng)端的技術(shù)選型上更加慎重了，最終采用了文檔更漂亮的。易用還真不易用，坑還真多。

需求重大調(diào)整，所有業(yè)務(wù)推倒重來（pc端主要任務(wù)涉及管理后臺(tái)類型的網(wǎng)站）；

開發(fā)周期很緊，過年前要上線；

公司pc端業(yè)務(wù)要求兼容到ie8；

2015年前端工資猛漲（特別是p2p這塊），離職潮加劇，前來面試的要么不合適（99%的面試者技術(shù)水平對(duì)不起那份高工資，也許是我要求太高），合適的人沒有選擇我們，最后只剩下2個(gè)人，一個(gè)做業(yè)務(wù)邏輯，一個(gè)做頁面重構(gòu)；

開發(fā)周期很緊，過年前要上線；

我剛?cè)肼毑痪?，之前的前端團(tuán)隊(duì)沒留下什么現(xiàn)成的代碼或模式，幾乎所有的東西都需要重新開發(fā)。

在這種情況下，為了更快的開展業(yè)務(wù)，花了兩三天時(shí)間，對(duì)技術(shù)選型做了一次任性而粗暴的預(yù)研：

拋棄了jquery這種基于dom操作的開發(fā)模式，后臺(tái)有大量的數(shù)據(jù)交互和綁定，開發(fā)起來比較慢，維護(hù)性不高。因?yàn)閡i都是完全自主，像easyui這類很重的框架一方面定制起來比較繁瑣，而且學(xué)習(xí)成本高，最重要的是個(gè)人不是很喜歡。

而當(dāng)下最流行的mvvm框架，像ng，vue，react都有一個(gè)致命問題--兼容性，雖然ng，react早期版本兼容ie8，當(dāng)考慮以后的維護(hù)升級(jí)，就沒有考慮。

最終選擇了兼容到ie6的avalon.js，終于使用上mvvm框架，雖然它只是個(gè)vm。
對(duì)比過1.5和之前版本，本著對(duì)作者的大名的神往及信任，項(xiàng)目使用了v1.5這個(gè)版本，為后來的開發(fā)買下伏筆。

本來想著技術(shù)棧統(tǒng)一，移動(dòng)端也準(zhǔn)備使用avalon.js。由于一些需求和開發(fā)優(yōu)先級(jí)等原因，遲遲沒有開始。
前期粗暴的預(yù)研，漸漸在pc端業(yè)務(wù)開發(fā)到了中期，一直在chrome上做開發(fā)，回頭做ie兼容性時(shí)，卻踩了史上最嚴(yán)重的坑。

于是，之后對(duì)移動(dòng)端的技術(shù)選型上更加慎重了，最終采用了文檔更漂亮的vuejs。雖然說是慎重之選，其實(shí)更是一個(gè)幸運(yùn)之選。

兩個(gè)庫(kù)我都在項(xiàng)目中使用，對(duì)vue越來越喜歡，而avalon越用越多槽點(diǎn)。

像這個(gè)issue，我想知其所以然。
雖然我通過用vuejs同理可知是因?yàn)樯婕吧商摂Mdom，組件模版必須有唯一的根元素。

這算我要求太高了，作者沒有那么多精力，那么接下來的有點(diǎn)難忍了。

avalon 在v1.5中居然不兼容ie8-，包括官方的例子。
同樣v2.0也是這樣，自己寫個(gè)教程，給的例子自己都不測(cè)試下。
他回復(fù) issue的原話如下：

ms-modal關(guān)閉不了自己改改，那個(gè)本來就是教程！

太不負(fù)責(zé)了吧！如果連兼容--avalon的最重要的最基礎(chǔ)一點(diǎn)都沒做到，那我就沒有使用他的必要了。

至于報(bào)錯(cuò)這項(xiàng)，比如父組件傳值給子組件一個(gè)子組件未定義過的值，它居然這樣報(bào)錯(cuò)

TypeError: 對(duì)象不支持此屬性或方法 onInit

那onInit是什么鬼？

vue中有一個(gè)局部組件的概念，起初不明白為什么要那么設(shè)計(jì)。后來慢慢發(fā)現(xiàn)，這個(gè)設(shè)計(jì)太重要了，特別是在把某一個(gè)組件太過復(fù)雜，把他拆分成更小的組件時(shí)，把這些更小的組件作為一個(gè)局部組件封裝在父組件內(nèi)部，而不會(huì)被暴露到外部。

反觀avalon的組件系統(tǒng)，內(nèi)層組件會(huì)把所有外層容器的屬性都繼承下來，而且組件一旦定義就是全局的了。而且組件的屬性沒有卻分內(nèi)部屬性和外部屬性，沒有了私有屬性和方法的概念，全部能被外部傳值給覆蓋。

對(duì)一些語法包裝上不是很友好，比如他寫的教程

有一次調(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)部的語法限制頗多。比如：教程中提到的

注意,有許多人喜歡用ms-if做非空處理,這是不對(duì)的,因此ms-if只是決定它是否插入DOM樹與否,ms-if里面的 ms-指令還是會(huì)執(zhí)行.
正確的做法是,當(dāng)你知道這里面有非空判定,需要用方法包起來

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)景沒注意）ms-if嵌套ms-for在ie8-不執(zhí)行。

可能因?yàn)関ue的作者設(shè)計(jì)出身，相比之下，vuejs的文檔設(shè)計(jì)的相當(dāng)漂亮。

且不說vue支持多種語言（好像中文文檔是社區(qū)提供的），avalon的教程中充斥這大量的口語話的表達(dá)，這點(diǎn)尚且可以忍。

作為一份教程，avalon沒有很好的把使用用法，注意事項(xiàng)清晰系統(tǒng)的表述，給出的例子七零八落，甚至還夾雜著bug。

作為一份api文檔，v1.5中只給出寥寥幾個(gè)api接口，以及一些簡(jiǎn)單的說明；v2.0有所進(jìn)步，但是連基本的完整性都沒做到，比如組件的api就沒有羅列。可能他想解釋：“你去看教程啊，里面有寫?。　?/p> 項(xiàng)目推廣

avalon 和國(guó)內(nèi)很多開源庫(kù)一樣，沒有做好推廣工作，當(dāng)然不是簡(jiǎn)單的拉來一堆人來助威，建個(gè)QQ群這樣的堆人模式。

之前加過很多相關(guān)技術(shù)群，感覺聊天的模式解決問題太沒效率了，不如在github上看issue提issue或者看源碼。

相比之下vue的作者在這方面更善于經(jīng)營(yíng)。

定義組件時(shí)用wbr標(biāo)簽兼容低版本ie，用html-minifer壓縮代碼時(shí)遇到一個(gè)問題

可能大家對(duì)這個(gè)標(biāo)簽的語意和用法理解不同，先給html-minfer提了個(gè)issue

根據(jù)issue上的回復(fù)，發(fā)現(xiàn)這個(gè)是我自己配置的坑

avalon2.0內(nèi)置了驗(yàn)證組件，但是卻赤裸裸的用起了promise，說好的兼容低版本呢。而且使用時(shí)里面夾雜著很多dom操作，不是應(yīng)該數(shù)據(jù)驅(qū)動(dòng)，告別dom操作

avalon2是一款基于虛擬DOM與屬性劫持的 迷你、 易用、 高性能 的 前端MVVM框架， 擁有超優(yōu)秀的兼容性, 支持移動(dòng)開發(fā), 后端渲染, WEB Component式組件開發(fā), 無需編譯, 開箱即用。

迷你 就不要內(nèi)置什么插件，我可能幾百年用不上。
易用 還真不易用，坑還真多。
擁有超優(yōu)秀的兼容性 最起碼的沒做好。
組件開發(fā) 封裝性太差
支持移動(dòng)開發(fā), 后端渲染 基于以上幾點(diǎn)，一個(gè)不太敢用，而且沒有什么優(yōu)勢(shì)可言