为什么CommonJS只说适合非浏览器的应用程序？
为什么不把它用作Javascript的通用组件模式，包括浏览器执行的Javascript？
一目了然，这似乎是模块化我目前正在进行的项目的一个好方法，它包括一个大的Javascript代码库，有很多组件，其中一些与其他组件交互。
CommonJS绝对适合浏览器，有一些注意事项。 CommonJS模块模式非常好（在我的偏见中），也是ECMAScript Harmony（计划下一个JavaScript语言版本）计划的模块系统的一个很好的踏脚石。 具体而言，Harmony模块将无法访问全局（“窗口”）对象。
一些人声称CommonJS模块不适合浏览器的原因是，没有一些服务器端的帮助，他们不能通过<script>标签加载。 例如，假设您有一个标记库，用于导出“convertToHTML”函数。 然后你可以创build一个如下所示的模块：
var convertToHTML = require("markdown").convertToHTML; exports.mangleSomeText = function() { // do something then call convertToHTML } 由于几个原因（范围未被包装，因此convertToHTML将被附加到窗口，通常不需要定义require，并且需要为每个模块单独创build导出），这不能通过脚本标记工作。
一个有一点服务器端帮助的客户端库可以允许通过脚本标签轻松加载。 或者，通过XMLHttpRequest加载脚本并执行eval（）的客户端库也可以工作，尽pipedebugging体验通常不太好。
目前一个相当合理的解决scheme，虽然也是CommonJS成员之间争议性争论的主题，但是RequireJS 。 使用RequireJS，你可以像这样编写你的模块：
define(function(require, exports, module) { var convertToHTML = require("markdown").convertToHTML; exports.mangleSomeText = function() { // do something then call convertToHTML } });
我们所做的只是在模块周围添加define（）位。 （你可能很容易让一台服务器做到这一点，所以你甚至不需要手动input定义部分）。
我已经亲自在几个项目上使用了RequireJS，并发现使用CommonJS模块不需要服务器端的简单方法。 还有很多其他的解决scheme，如果你不依赖于运行静态JS文件，标准的CommonJS模块是一个很好的select。
（ObDisclaimer：我开始了CommonJS项目，所以我显然有偏见。）
