ESL 发布 2.0

jopen 10年前

ESL 是一个浏览器端、符合AMD的标准加载器，适合用于现代Web浏览器端应用的入口与模块管理。

通过右键另存的方式可以下载ESL:

今天，ESL release 了 2.0.4。到这里本应该完了，不过好像内容少了点。为了凑数，还是多扯几句吧：

为什么使用ESL而不用RequireJS

很官方的答案是，ESL比RequireJS：

  • 体积更小 (Smaller)
  • 性能更高 (Higher performance)
  • 更健壮 (More Robustness)
  • 不支持在非浏览器端使用 (Browser only)
  • 依赖模块用时定义 (Lazy define)

作为ESL的主要开发者，我个人的答案是：

  1. 上面的吹牛都不是吹牛，都是真的。
  2. 蚊子再小也是肉，有更小性能更高的干嘛不用？
  3. 反正换个Loader没成本的咯，就改个script的src，分分钟的事。不行再换回来也是分分钟的事。只有选Framework选对象这种事情，选错了替换成本才会比较高。

诚信是做人之本，欺瞒消费者是令人痛恨的行为。所以在这里要说一下：RequireJS提供了一些非AMD标准的功能，比如data-main、比如可以直接require一个url。ESL是不支持的。如果你用到这些功能，并且觉得这些功能很有用的话，还是不要换了。

2.x和1.x相比是breaking change吗

有的ESL 1.x的使用者，一看到第一位版本号加了，是不敢升级的。在common sense里，第一位版本号的增加代表的是breaking change。但是，ESL本身是个AMD Loader啊，breaking change难道就不是AMD了么？显然ESL不敢这么玩。

真实情况是这样的：我们完成了对shim的支持。ESL已经做到AMD特征完备了。这也算是个里程碑吧。所以，这一次我们跳到了2.x。

为什么发布2.0是2.0.4而不是2.0.0

大约1个月前，我们就已经release 2.0.0。虽然有完善的测试用例做支撑，但我们觉得，万事无绝对。所以我们在一些Baidu的产品线中先使用验证，这些产品线的业务场景都比较复杂。验 证过程中还真发现一个在包含resource的复杂场景下和加载过程有关的bug: issue35

现在我们觉得，应该比较稳定了，所以在blog上发出来，给出一个交代。

但是，下面这个理由应该更可信一点：快过年了，大家都歇了，没人写blog，只能发这种东西来凑数了。

下载下来用？还是直接使用ESL提供的CDN？

先看看ESL提供的CDN引用地址：

    
       <!-- compressed -->     
      
       <script src="http://s1.bdstatic.com/r/www/cache/ecom/esl/2-0-4/esl.js"></script>     
      
       <!-- source -->     
      
       <script src="http://s1.bdstatic.com/r/www/cache/ecom/esl/2-0-4/esl.source.js"></script>

一看这个URL就很山寨，有没有？有没有？？？？为了让大家放心使用，在这里偷偷爆尿下，我们很多在Baidu搜索结果页面上的资源就是用的这个CDN，稳定性很高。

当然，下载使用还是CDN使用本来就是开发者的偏好，大家自己决定。这里只是想提一句，我们提供的CDN引用是稳定有诚意的，不是坑爹的。

最后

如果你开发中还是各种手工引入JS，那么，建议你使用AMD的方式开发。我们不能总是活在原始社会。

如果你已经在用SeaJS，在已有项目中也没必要换到AMD来，虽然AMD应用面更广泛一些。

如果你想更深入了解AMD，可以看看我之前写的几篇写到吐血、写到今年都不想再写了的blog。内容比较长，很能考验读者的耐心。其中，第三篇的一些内容，已经过时了：

如果你觉得我们还算有诚意，给个star支持下呗，反正不花钱。

来自：http://efe.baidu.com/blog/esl-2.0/