19 — node 模塊化 及 CommonJS規範 — CommonJS 的由來及各組織與 JS 的關係

ECMAScript  對於不一樣的環境（運行平臺），設計結構，理念，使用方式截然不同。

1，瀏覽器 ：DOM BOM

2，NodeJS ：FS,HTTP 內置模塊 ；  第三方模塊 ； 內置模塊

3，桌面級應用及其餘平臺 ： Window Mac 系統 及 其餘操做平臺

 

 

一，CommonJS 規範的由來

JavaScript 語言一誕生就是之服務於瀏覽器。

JS 的表現能力取決與宿主環境提供的 API

1，web1.0時代 ：W3C提供了對瀏覽器的支持

2，web2.0時代 ：隨着 HTML5 的發展 ， 更多的標準 API 出如今瀏覽器中 。 可是，在後端 JS 的標準的制定紋絲未動

3，2009年1月的時候，Kevin Dangoor 寫了這篇文章 https://www.blueskyonmars.com/2009/01/29/what-server-side-javascript-needs/，提名爲 ServerJS規範。2009年8月，改名爲 CommonJS 。 

以顯示 API 的更普遍實用性

 

　　————  =>文章開始  ————

 

服務器端JavaScript須要什麼

2009年1月29日14：00·816字·4分鐘閱讀

服務器端JavaScript技術已經存在了很長時間。Netscape早在1996年就在他們的服務器軟件中提供了服務器端JavaScript，而Helma也存在了不少年。可是，服務器端開發在過去幾年中發生了很大變化。

Aptana的Jaxer提供了一個創新的視圖，說明如何利用在線路（客戶端和服務器）兩端運行的JavaScript環境。很是方便的通訊和在客戶端和服務器之間輕鬆共享代碼的能力是在服務器上運行JavaScript的巨大好處。

Jaxer和Helma是有趣的項目，能夠確定（還有不少其餘項目！）。可是我在服務器上看到的JavaScript缺失的並非有趣的項目，而是一個有用的生態系統。在Python中工做的人喜歡談論Web框架的碎片和諸如此類的東西，但與JavaScript的碎片相比，這沒什麼。

例如，JavaScript須要交叉解釋器標準庫。值得慶幸的是，存在一些標準庫（從瀏覽器繼承的部分）。因此，你獲得正則表達式和日期。可是，文件和目錄呢？爲何不能在Rhino，Spidermonkey，V8和JSCore中使用相同的API？

少數標準接口。鏈接到數據庫並運行查詢是一個很好理解和常見的問題。在Rhino中，您可使用JDBC。可是，JavaScript確實應該有本身的交叉解釋器標準，如Python的DBAPI。還應該能夠採用最初部署在運行Spidermonkey的Apache模塊後面的webapp，而後經過標準的Web服務器/ Web應用程序界面將其放在Jetty後面。

JavaScript須要一種標準方式來包含其餘模塊，而且這些模塊能夠存在於謹慎的命名空間中。有很簡單的方法能夠執行命名空間，可是沒有標準的編程方式來加載模塊（一次！）。這很是重要，由於服務器端應用程序能夠包含大量代碼，而且可能會混合和匹配符合這些標準接口的部分。

須要有一種方法來打包代碼以進行部署和分發，並進一步安裝軟件包。Linux人員會正確地指出他們能夠只輸入「apt get」（或yum，或其餘），他們的工做就完成了。可是有不少人使用Mac和Windows，須要一種方便的方法來設置他們的開發環境，並打包他們爲部署和其餘人使用而編寫的代碼。

部分分發和安裝問題是包存儲庫。我不知道JSAN是否就是那裏的答案，但我知道安裝軟件包及其依賴項的簡單方法對於人們可能在他們的應用程序中彙總的庫數量有很大的不一樣。

並且，除了全部這些優勢以外，咱們還會得到模板引擎，對象關係映射器，中間件，打包應用程序等。事實上，其中許多已經存在。可是，問題是他們沒有共同的依據。這就是阻止生態系統發展的緣由。

若是您搜索WSGI的Python包索引（用於將Web應用程序與Web服務器鏈接的Python標準），您今天將找到180個包...服務器，中間件，完整的應用程序。而這些只是其列表中包含「WSGI」的軟件包。這就是生態系統的樣子。Java有一個，Ruby有一個，JavaScript須要一個。

值得注意的是，因爲使用了通用的標準庫，許多WSGI組件能夠在CPython，Jython和IronPython上保持不變。JavaScript在C中有一系列實現，以及Java和.Net實現，只須要對某些接口等進行一些協議。在全部這些地方運行的庫能夠吸引更多用戶，而且但願有更多的提交者來幫助圖書館發展。

我在這裏描述的不是技術問題。這是一我的們聚在一塊兒並決定前進並開始創建更大，更冷的東西的問題。

爲此，我創建了一個新的ServerJS小組，但願讓有興趣的各方進行交流，甚至可讓咱們面對面地共同製做一些代碼並解決某些界面問題。已經有大量的JavaScript代碼集合，讓咱們看看咱們是否可使全部代碼更有價值。

在Mozilla的Web開發人員工具組中，咱們有一個普遍的開放式章程，可幫助軟件開發人員充分利用開放式Web。盡一切努力幫助服務器端JavaScript社區成長和蓬勃發展固然能夠成爲其中的一部分。

（在有人說「爲何不僅是使用Ruby / Python / Java / C＃？」以前，我只想說這是一個徹底不一樣的問題，我不會在這篇文章中解決這個問題。）

更新：該組如今稱爲CommonJS。

 

　　————  =>文章結束 ————