摘要:最終選擇了兼容到的,終于使用上框架,雖然它只是個。沒有對比就沒有傷害本來想著技術棧統一,移動端也準備使用。于是,之后對移動端的技術選型上更加慎重了,最終采用了文檔更漂亮的。易用還真不易用,坑還真多。
吐槽 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壓縮代碼時遇到一個問題
</>復制代碼
可能大家對這個標簽的語意和用法理解不同,先給html-minfer提了個issue
根據issue上的回復,發現這個是我自己配置的坑
任性的代碼avalon2.0內置了驗證組件,但是卻赤裸裸的用起了promise,說好的兼容低版本呢。而且使用時里面夾雜著很多dom操作,不是應該數據驅動,告別dom操作
總結一下</>復制代碼
avalon2是一款基于虛擬DOM與屬性劫持的 迷你、 易用、 高性能 的 前端MVVM框架, 擁有超優秀的兼容性, 支持移動開發, 后端渲染, WEB Component式組件開發, 無需編譯, 開箱即用。
迷你 就不要內置什么插件,我可能幾百年用不上。
易用 還真不易用,坑還真多。
擁有超優秀的兼容性 最起碼的沒做好。
組件開發 封裝性太差
支持移動開發, 后端渲染 基于以上幾點,一個不太敢用,而且沒有什么優勢可言
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/90925.html
摘要:近日,他開通了賬號,并發表了第一篇文章,透露出要替換的核心部件解析器的想法。這篇文章分析了當前的解析器的諸多缺陷,并介紹了解析器的優點,令人振奮。但問題是,如果你這樣寫語法,解析器不會起作用,將會罷工。 showImg(https://segmentfault.com/img/remote/1460000019893712?w=3936&h=2624); 花下貓語: Guido van...
摘要:下的包含很多匹配規則正則表達式,每一條代表加載什么類型的資源文件,上面寫的就是加載樣式文件,并使用和加載。現在問題來了,我想喝瓶茅臺自動添加瀏覽器產商前綴。沒問題,強大的生態圈給你提供了,一個更高大上的。 開始 webpack 之旅 npm install webpack --save-dev 這里如果沒有指定 -g全局安裝,那么需要調用 node_modules 下的 webpack...
閱讀 2912·2021-10-19 10:09
閱讀 3131·2021-10-09 09:41
閱讀 3379·2021-09-26 09:47
閱讀 2694·2019-08-30 15:56
閱讀 599·2019-08-29 17:04
閱讀 985·2019-08-26 11:58
閱讀 2509·2019-08-26 11:51
閱讀 3361·2019-08-26 11:29