是的，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如果想解决以下这两个问题，可能得伤筋动骨了。
<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>
<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。。。。
说累了，以后再说。
