摘要：jqueryUI不好用, 该落伍, 我不知道这个论点是如何出现的, 但是我敢说执有这个观点的, 50%的人没用过, 40%的人只是把jqueryUI当做现成的纯UI库来使用, 只有剩下的10%是研究透了jqueryUI最后因业务的需要投身于新一代框架麾下的.因为在你没见过的地方, jqueryUI以你未曾想过的形态做了很多不可思议的东西.举几个适用场景: 网站方面: 大部分开发流程还是h
jqueryUI不好用, 该落伍, 我不知道这个论点是如何出现的,
但是我敢说执有这个观点的, 50%的人没用过, 40%的人只是把jqueryUI当做现成的纯UI库来使用, 只有剩下的10%是研究透了jqueryUI最后因业务的需要投身于新一代框架麾下的.
因为在你没见过的地方, jqueryUI以你未曾想过的形态做了很多不可思议的东西.
举几个适用场景:
网站方面: 大部分开发流程还是html+css+js的传统一套, 在这个层面上所有框架一视同仁, 纯jquery手撸的效率已经足够快了, jqueryUI作为辅助UI组件, 虽然样式比起bootstrap是要low点, 但凡设计有点想法, 最后样式不都是要统一覆盖重写么.
小型应用: 也可以理解为简单组件, 基本没有比jqueryUI快的, 这是人家的老本行, jqueryUI本来就是个UI库, 所有默认组件最终都是继承自Widget基类, widget组件的数据与ui交互方式都可以归结为三种: 设定初始options; 修改options; 通过options修改view. 本质上就是数据单向绑定,
在此基础上约定规则, 可以构造出新的优秀特性.
也因此jqueryUI得天独厚, 只需引入核心文件widget就能在jquery环境下构建任何应用.
此环境下它绝对是开发速度最快的前端库之一.
大型应用: 这是jqueryUI真正的短板, 因为组件库的设计只到了组件这层, 更高更抽象的框架层面, jqueryUI根本没有去涉及,
但是并不是说没有办法构建巨型web应用,
以jqueryUI为框架选型的应用, 需要实现应用的高度抽象, 从高层的组件里调用底层的组件, 并通过回调等方式来实现低层数据反馈回高层.
比方我们做一个编辑器, 场景有许多键值, 其中一项键值需要在某个dialog里编辑, 那么我们在场景层调用dialog弹窗时, 给options传入一个callback, 当弹窗编辑完毕, 再将绑定在dialog上的数据通过callback传递回场景组件就实现了组件通信.
即是, 如果能力足够强, 你可以用组件构造的方式层层堆叠实现一个巨型web单页应用.
就我目前的经验来看, 几十万行还不是上限.
但这几十万行的代码, 已经极其难维护了.
widget组件嵌套, 调用栈过深, 到处充斥着难以摸清意义的callback,
让维护者举步维艰,
所以说,
jqueryUI的问题只在于大型应用的可维护性上,
他虽然将jquery的从单纯的dom操作上扩展到ui组件层面,
但是却始终没有达到应用框架的层次, 这也是jquery的真正短板.
但是如果不能理解其真正症结, 只是跟风觉得落伍, 抛出样式老土太丑的观点的,
我只能理解为你根本没理解jqueryUI到底是什么..
