Jquery之美中不足
在QWrap群里讨论时,有同学问“jquery/yui等已做到极致,我们有没必要再重复造一个叫QWrap的轮子?”
是的,jquery成功挖掘selector、链式用法、gsetter用法、很多精简命名,等等,让前端变得轻松简单,为Web开发作出巨大贡献。
不过,它也有一些不尽人意的地方。
1。关于代码坨之一。
一直觉得jquery是个个人英雄主义的产物,有耐心看完他代码的,绝对少于百分之一。
sizzle独立出来后,ms有些改观。
可一坨一坨并且相互牵连的风格,还是在sizzle与jquery到处都是。
有时想:John如果不写代码了,谁会愿意来接手这些坨坨。
2。关于代码坨之二。
不知有没有组件开发者想过“依赖jquery开发出一个能不依赖jquery而独立运行的组件”?
这是奇怪的需求吗?----好像不是。
有这样的需求吗?----很多同学会说:“jquery已经树大根深好乘凉可依赖,为什么还要独立运行。”
也是,组件开发者的水平一般都还不错,他们会想办法解决这些问题的。如果有这样的需要,他们会去找到对应的方法库的。
不过,这也说明了,jquery不能满足这些人的需求。
因为jquery就是个代码坨。想拆成静态方法库,那几乎是不可能的。
3。关于“专注于dom”之一。
不知道该说好,还是该说不好。
觉得jquery的团队,绝对有能力做一个全面的框架,而不只是停在“专注于dom”这一点上。
使用jquery与jquery组件,我们可能还得自己去找个种子文件,来作异步加载等。
因为这些的种子需求,其实是跟dom没啥紧密关系的,所以jquery可以完全不顾-----倒是很会偷懒啊。
另,关于种子文件,YUI3把use当核心点是个不错的创意,可惜发挥得有点太过。到YUI3后,我想只用他的selector来作个性能比对,竟然要加载一推文件才能做到。
4。关于“专注于dom”之二。
“jquery专注于dom”,
那字符串的trim,需要在jquery里吗?----貌似没必要吧。不过jquery顺手提供了。类似的还有parseJSON、globalEval等。
那字符串模板功能(tmpl)呢?----模板明显是应该基于字符串的,因为字符串模板常用来组织html字符,所以,jquery会把它牵强的放进来。并且是基于dom的。----我实在想说:真的很牵强。
我们在项目中,可能还会用到很多跟字符串有关的功能(trim|subByte|encode4Hhtml等)、跟object有关的功能(get|dump|mix等)、跟数组有关的功能(forEach|map),等等。
这些问题,jquery都没有帮我们解决的意思,那我们是不是都得再另请高明或自已解决?
5。关于sizzle。
A:有时候觉得sizzle是个半成品,一些本来可以顺手提供的功能,却没提供出来。
例如:
selector2filter(selector) //把一个selector转化成一个过滤函数。
filter(els,selector,refEl) //以ref为参考元素,按selector条件过滤els。例如,在delegate时会用到。由于sizzle没提供,导致$('#id').delegate('>li','click',handle)中的'>li'的参考元素不是#id对应的对象
B:sizzle如果想解决以下这两个问题,可能得伤筋动骨了。
C:一点小想法,Sizzle的代码有点多。YUI后有13K之多,去掉他额外加的几个简写,也还有11K多。
6。。。。
说累了,以后再说。
是的,jquery成功挖掘selector、链式用法、gsetter用法、很多精简命名,等等,让前端变得轻松简单,为Web开发作出巨大贡献。
不过,它也有一些不尽人意的地方。
1。关于代码坨之一。
一直觉得jquery是个个人英雄主义的产物,有耐心看完他代码的,绝对少于百分之一。
sizzle独立出来后,ms有些改观。
可一坨一坨并且相互牵连的风格,还是在sizzle与jquery到处都是。
有时想:John如果不写代码了,谁会愿意来接手这些坨坨。
2。关于代码坨之二。
不知有没有组件开发者想过“依赖jquery开发出一个能不依赖jquery而独立运行的组件”?
这是奇怪的需求吗?----好像不是。
有这样的需求吗?----很多同学会说:“jquery已经树大根深好乘凉可依赖,为什么还要独立运行。”
也是,组件开发者的水平一般都还不错,他们会想办法解决这些问题的。如果有这样的需要,他们会去找到对应的方法库的。
不过,这也说明了,jquery不能满足这些人的需求。
因为jquery就是个代码坨。想拆成静态方法库,那几乎是不可能的。
3。关于“专注于dom”之一。
不知道该说好,还是该说不好。
觉得jquery的团队,绝对有能力做一个全面的框架,而不只是停在“专注于dom”这一点上。
使用jquery与jquery组件,我们可能还得自己去找个种子文件,来作异步加载等。
因为这些的种子需求,其实是跟dom没啥紧密关系的,所以jquery可以完全不顾-----倒是很会偷懒啊。
另,关于种子文件,YUI3把use当核心点是个不错的创意,可惜发挥得有点太过。到YUI3后,我想只用他的selector来作个性能比对,竟然要加载一推文件才能做到。
4。关于“专注于dom”之二。
“jquery专注于dom”,
那字符串的trim,需要在jquery里吗?----貌似没必要吧。不过jquery顺手提供了。类似的还有parseJSON、globalEval等。
那字符串模板功能(tmpl)呢?----模板明显是应该基于字符串的,因为字符串模板常用来组织html字符,所以,jquery会把它牵强的放进来。并且是基于dom的。----我实在想说:真的很牵强。
我们在项目中,可能还会用到很多跟字符串有关的功能(trim|subByte|encode4Hhtml等)、跟object有关的功能(get|dump|mix等)、跟数组有关的功能(forEach|map),等等。
这些问题,jquery都没有帮我们解决的意思,那我们是不是都得再另请高明或自已解决?
5。关于sizzle。
A:有时候觉得sizzle是个半成品,一些本来可以顺手提供的功能,却没提供出来。
例如:
selector2filter(selector) //把一个selector转化成一个过滤函数。
filter(els,selector,refEl) //以ref为参考元素,按selector条件过滤els。例如,在delegate时会用到。由于sizzle没提供,导致$('#id').delegate('>li','click',handle)中的'>li'的参考元素不是#id对应的对象
B:sizzle如果想解决以下这两个问题,可能得伤筋动骨了。
View Code
<h1 id="head1">主题</h1>
<ul><li>明细1.1</li><li>明细1.2</li></ul>
<ul><li>明细2.1</li><li>明细2.2</li></ul>
<script>
alert($('#head1~ul>li').length);//应该是4而不是0。因为sizzle在取候选集时偷懒了,没有认真的处理候选集问题
</script>
View Code
<ul>
<li>
<div>
<div>
<span>需要的</span>
</div>
</div>
</li>
<li>
<h1>
<div>
<span>不需要的</span>
</div>
</h1>
</li>
</ul>
<script>
alert($('li>div span').length); //应该是1,而不是0。因为sizzle在过滤时偷了懒,把回溯的情况给忽略了。
</script>
C:一点小想法,Sizzle的代码有点多。YUI后有13K之多,去掉他额外加的几个简写,也还有11K多。
6。。。。
说累了,以后再说。