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。

 

　　————  =>文章结束 ————