abstract：jqueryUI不好用, 該落伍, 我不知道這個論點是如何出現(xiàn)的, 但是我敢說執(zhí)有這個觀點的, 50%的人沒用過, 40%的人只是把jqueryUI當做現(xiàn)成的純UI庫來使用, 只有剩下的10%是研究透了jqueryUI最后因業(yè)務(wù)的需要投身于新一代框架麾下的.因為在你沒見過的地方, jqueryUI以你未曾想過的形態(tài)做了很多不可思議的東西.舉幾個適用場景: 網(wǎng)站方面: 大部分開發(fā)流程還是h

jqueryUI不好用, 該落伍, 我不知道這個論點是如何出現(xiàn)的, 

但是我敢說執(zhí)有這個觀點的, 50%的人沒用過, 40%的人只是把jqueryUI當做現(xiàn)成的純UI庫來使用, 只有剩下的10%是研究透了jqueryUI最后因業(yè)務(wù)的需要投身于新一代框架麾下的.

因為在你沒見過的地方, jqueryUI以你未曾想過的形態(tài)做了很多不可思議的東西.
舉幾個適用場景:

網(wǎng)站方面: 大部分開發(fā)流程還是html+css+js的傳統(tǒng)一套, 在這個層面上所有框架一視同仁, 純jquery手擼的效率已經(jīng)足夠快了, jqueryUI作為輔助UI組件, 雖然樣式比起bootstrap是要low點, 但凡設(shè)計有點想法, 最后樣式不都是要統(tǒng)一覆蓋重寫么.

小型應(yīng)用: 也可以理解為簡單組件, 基本沒有比jqueryUI快的, 這是人家的老本行, jqueryUI本來就是個UI庫, 所有默認組件最終都是繼承自Widget基類, widget組件的數(shù)據(jù)與ui交互方式都可以歸結(jié)為三種: 設(shè)定初始options; 修改options; 通過options修改view. 本質(zhì)上就是數(shù)據(jù)單向綁定,
在此基礎(chǔ)上約定規(guī)則, 可以構(gòu)造出新的優(yōu)秀特性.
也因此jqueryUI得天獨厚, 只需引入核心文件widget就能在jquery環(huán)境下構(gòu)建任何應(yīng)用.
此環(huán)境下它絕對是開發(fā)速度最快的前端庫之一.

大型應(yīng)用: 這是jqueryUI真正的短板, 因為組件庫的設(shè)計只到了組件這層, 更高更抽象的框架層面, jqueryUI根本沒有去涉及,

但是并不是說沒有辦法構(gòu)建巨型web應(yīng)用,
以jqueryUI為框架選型的應(yīng)用, 需要實現(xiàn)應(yīng)用的高度抽象, 從高層的組件里調(diào)用底層的組件, 并通過回調(diào)等方式來實現(xiàn)低層數(shù)據(jù)反饋回高層.
比方我們做一個編輯器, 場景有許多鍵值, 其中一項鍵值需要在某個dialog里編輯, 那么我們在場景層調(diào)用dialog彈窗時, 給options傳入一個callback, 當彈窗編輯完畢, 再將綁定在dialog上的數(shù)據(jù)通過callback傳遞回場景組件就實現(xiàn)了組件通信.

即是, 如果能力足夠強, 你可以用組件構(gòu)造的方式層層堆疊實現(xiàn)一個巨型web單頁應(yīng)用.

就我目前的經(jīng)驗來看, 幾十萬行還不是上限.

但這幾十萬行的代碼, 已經(jīng)極其難維護了.
widget組件嵌套, 調(diào)用棧過深, 到處充斥著難以摸清意義的callback,
讓維護者舉步維艱,    

所以說,
jqueryUI的問題只在于大型應(yīng)用的可維護性上,

他雖然將jquery的從單純的dom操作上擴展到ui組件層面,
但是卻始終沒有達到應(yīng)用框架的層次, 這也是jquery的真正短板.


但是如果不能理解其真正癥結(jié), 只是跟風覺得落伍, 拋出樣式老土太丑的觀點的,
我只能理解為你根本沒理解jqueryUI到底是什么..