思考：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 编辑 ]