标题:
思考:zepto埋了不少坑,选用js框架需要谨慎
[打印本页]
作者:
xiexie
时间:
2016-12-14 10:17
标题:
思考:zepto埋了不少坑,选用js框架需要谨慎
最近公司在做一个活动,应用到ajax的jsonp跨域请求数据,我们项目用zepto框架,按常理用同步请求的方式把请求数据接口封装成一个有返回值函数,结果无论如何都获取不到success返回的数据,写法的确没有毛病,后来换成jquery框架,能正常返回数据了,原来zepto不支持jsonp的同步方式,不知道是不是出于安全考虑?
<script>
function get_token() {//评分答题得排名
var url = "port/json.php";
var param = {};
var gtoken = "1";
param.transactionType = "100208";
$.ajax({
url: url,
data: param,
dataType: "jsonp",
async: false,
success:function(dataObj){
if(dataObj !== "" && dataObj.resCode == "000") {
gtoken = dataObj.question_Token;
}
gtoken = "2";
console.log("gtoken1:"+gtoken);
}
});
console.log("gtoken2:"+gtoken);
}
get_token();
</script>
下面是一网友的总结,建议不要使用zepto:
1、自己/公司/项目组所写和所积累(网上下的)的js函数都是以jQuery插件的写法来写的,如果要换到zepto上的话那么每个都要改一点。而且通常都是要同时做PC端和手机端,PC端无疑是要用jQuery,如果手机端用zepto,就会产生两份js插件库,大大增加了维护成本和难度。
2、有一部分实用的API被裁剪了,让编程变得困难,本来一句话搞定的事,要自己多写几句才能搞定,一开始还不知道是怎么报的错。
3、虽然zepto比jQuery小,但其实文件的大小只在第一次打开该网站时有影响,后面都是使用304本地缓存无需重新下载,文件大小的区别已经没影响了。就算是第一次下载,移动端不需要IE可以使用jQuery2以上版本,况且现在网站都用GZip压缩,30K左右的大小也能接受吧。
4、有一个网站对这几个库进行性能测试,结果是jQuery比zepto的执行效率要高,这就让我怀疑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事件。
8、如果一些插件需要jQuery而并不适应zepto,但项目主要用zepto,那么就很可能会引入了两个库。很多事件没处理好的话就会触发两次,大大增加了填坑复杂度,而不是花精力去关注真正的业务逻辑。
9、网上还有zepto各种小BUG的解决小技巧和方案。但是我认为,一个优秀的框架应该是帮助开发人员减少重复工作的,而不是埋下一堆堆莫名其妙的问题,让开发者纠结了又纠结,找了又找,引入一堆本来并不需要的库/插件,让管理变得更多复杂。另外,多个分散小文件的下载比一个稍大的文件还要耗时(参考CSS Sprite)。
[
本帖最后由 xiexie 于 2016-12-14 10:20 编辑
]
欢迎光临 PHP开发笔记 (http://phpvi.com/)
Powered by Discuz! 6.1.0