是的，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。。。。
說累了，以後再說。