ESL 發布 2.0

ESL 是一個瀏覽器端、符合AMD的標準加載器，適合用于現代Web瀏覽器端應用的入口與模塊管理。

通過右鍵另存的方式可以下載ESL:

• 壓縮代碼 (Compressed)
• 源碼 (Source)

今天，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。內容比較長，很能考驗讀者的耐心。其中，第三篇的一些內容，已經過時了：

• 玩轉AMD系列 - 設計思路篇
• 玩轉AMD系列 - 應用實踐篇
• 玩轉AMD系列 - Loader篇

如果你覺得我們還算有誠意，給個star支持下唄，反正不花錢。

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