别再迷信 zepto 了

jopen 8年前
 

希望网上公开课的老师们不要再讲移动端网页用zepto了,坑了无数鸟啊 ~~~。

1、自己/公司/项目组所写和所积累(网上下的)的js函数都是以jQuery插件的写法来写的,如果要换到zepto上的话那么每个都要改一 点。而且通常都是要同时做PC端和手机端,PC端无疑是要用jQuery,如果手机端用zepto,就会产生两份js插件库,大大增加了维护成本和难度。

2、有一部分实用的API被裁剪了,让编程变得困难,本来一句话搞定的事,要自己多写几句才能搞定,一开始还不知道是怎么报的错。

3、虽然zepto比jQuery小,但其实文件的大小只在第一次打开该网站时有影响,后面都是使用304本地缓存无需重新下载,文件大小的区别已经没影 响了。就算是第一次下载,移动端不需要IE可以使用jQuery2以上版本,况且现在网站都用GZip压缩,30K左右的大小也能接受吧。 别再迷信 zepto 了

4、有一个网站对这几个库进行性能测试,结果是jQuery比zepto的执行效率要高,这就让我怀疑zepto的水平了,明明是裁剪的、为移动优化的但性能却更差。 性能测试网站链接>> (说明:这个测试网站中,得出的数值越大说明效率越高性能越好,红色底为效率最低,绿色底为效率最高,我截图只截了最常用的两个写法的效率,苹果和安卓的也测了都是zepto的比jQuery的低,约为60%)

Chrome下: 别再迷信 zepto 了

Firefox下: 别再迷信 zepto 了

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,也只是昙花一现而已,或许根本就不是一支昙花而是一朵奇葩。