希望網上公開課的老師們不要再講移動端網頁用zepto了，坑了無數鳥啊 ~~~。
1、自己/公司/項目組所寫和所積累（網上下的）的js函數都是以jQuery插件的寫法來寫的，如果要換到zepto上的話那么每個都要改一點。而且通常都是要同時做PC端和手機端，PC端無疑是要用jQuery，如果手機端用zepto，就會產生兩份js插件庫，大大增加了維護成本和難度。
2、有一部分實用的API被裁剪了，讓編程變得困難，本來一句話搞定的事，要自己多寫幾句才能搞定，一開始還不知道是怎么報的錯。
3、雖然zepto比jQuery小，但其實文件的大小只在第一次打開該網站時有影響，后面都是使用304本地緩存無需重新下載，文件大小的區別已經沒影響了。就算是第一次下載，移動端不需要IE可以使用jQuery2以上版本，況且現在網站都用GZip壓縮，30K左右的大小也能接受吧。
4、有一個網站對這幾個庫進行性能測試，結果是jQuery比zepto的執行效率要高，這就讓我懷疑zepto的水平了，明明是裁剪的、為移動優化的但性能卻更差。性能測試網站鏈接>>（說明：這個測試網站中，得出的數值越大說明效率越高性能越好，紅色底為效率最低，綠色底為效率最高，我截圖只截了最常用的兩個寫法的效率，蘋果和安卓的也測了都是zepto的比jQuery的低，約為60%）
Chrome下：
Firefox下：
5、一個在核心領域核心功能上沒有足夠優勢的庫，它作者的水平是否值得信賴？它還會為以后埋下多少坑？
6、理論上說zepto的tap事件會比click事件少了那300毫秒的延遲，但一般手機端的點擊事件基本都要Ajax請求或者跳轉頁面，相比網絡請求的延遲來說這300毫秒微不足道。而且jQuery也有相應的插件。反正在實際使用中並沒有感到那傳說中300毫秒的不順暢。最近了解到說安卓4.1以上meta標簽設置禁止縮放就可以讓瀏覽器禁用300ms的延時了。
7、zepto使用touch相關的事件模擬出tap、longTap等事件，目的為解決click事件的300ms 延時，但有個很大的問題是tap事件會“穿透”，“穿透”又會導致一系列問題。業內有個辦法是使用一個fastclick的庫，用回click事件。>>更多關於fastclick和300ms延時
8、如果一些插件需要jQuery而並不適應zepto，但項目主要用zepto，那么就很可能會引入了兩個庫。很多事件沒處理好的話就會觸發兩次，大大增加了填坑復雜度，而不是花精力去關注真正的業務邏輯。
9、網上還有zepto各種小BUG的解決小技巧和方案 >>比如這里。但是我認為，一個優秀的框架應該是幫助開發人員減少重復工作的，而不是埋下一堆堆莫名其妙的問題，讓開發者糾結了又糾結，找了又找，引入一堆本來並不需要的庫/插件，讓管理變得更復雜。另外，多個分散小文件的下載比一個稍大的文件還要耗時（參考CSS Sprite）。
有些東西就是曇花一現，開始看起來很驚艷，但實際用起來到處是坑。zepto，也只是曇花一現而已，或許根本就不是一支曇花而是一朵奇葩。