大家好

昨天我們提到了 CommonJS 這個模組化標準的發展

他是一個同步 Loading (也就是 A Load 完才會 Load B) 的模組化規範

今天我們在寫一個後端 Server，讓所有的 Dependency 在一開始就 Loading 完並不是什麼大問題，頂多開啟 Server 的時間比較長而已

但是今天在瀏覽器的環境

我們載入模組的速度不像是直接讀硬碟那麼快

而是會牽涉到網路的速度！

這樣的限制，導致許多人對於 CommonJS 原生的同步式加載有意見

歷史

詳細內容可以參考這篇的內容

基本上內容是

1. 早期 CommonJS 叫做 ServerJS，再推出他們自己的 1.0 版本規範後發展很好

2. 後來他們想要進一步將 ServerJS 推廣到瀏覽器，就把社群名稱改叫做 CommonJS

3. 但是瀏覽器跟伺服器端環境有很大的不同，這時候他們內部的人各有各的看法，這時候有兩個主要的流派

4. CommonJS 本身就夠用了，直接移植到瀏覽器上就好

5. 要新開發非同步式的模組規範，比較能適應瀏覽器端的環境

而 AMD 就是另一種試著開發出瀏覽器專屬模組的「規範」

後來

但是 AMD 規範本身使用的 define 語法

define(
  module_id /*optional*/, 
  [dependencies] /*optional*/, 
  definition function /*function for instantiating the module or object*/
);

以及對 require() 實作行為的定義分歧

將會導致你會無法在前端 Project 中使用任何 CommonJS style 的 Node 函式庫

最後，AMD 就和他的一種前端 runtime RequireJS 在開發上比不上 CommonJS 派的前端模組(他們使用了哪種 runtime 後續會介紹)

CommonJS 現在與未來

後來出現了一項工具，叫做 Webpack

基本上 Webpack 的概念很有趣，他是這樣想的

「在我實作瀏覽器版本的 CommonJS 模組時，可不可以一起支援 npm 上的套件，這樣我就可以使用 npm 來整理我的函式庫了」

(我知道我們還沒介紹到 npm)

這一舉動簡直是驚為天人

因為以往我們在前端，管理套件的方式還是沒受後端的 npm 所感化

現在來了一個 Webpack，他既然把不相容的接口都補齊了！

明天

在明天的時候

我們將會介紹幾個主題

1. 我們之前在解釋 Node.js 時，刻意跳過的「npm」
2. Webpack 的野望(Webpack不只是只支援 npm, commonjs, 他還有一項創舉 - 就是 loader，將會在後續介紹，以及他把以前所有開發工具，像是 reload 都自己包含進去了)
3. ES7+ 的嶄新發展
4. Babel 這個專案如何解決標準不相容問題(以及他怎麼設定)

今天的主題就到這裡了

明天見！