javascript - 为什么说CommonJS只适合非浏览器应用程序？

为什么不将其用作Javascript(包括浏览器执行的Javascript)的常规组件模式？

乍一看，这似乎是对我当前正在从事的项目进行模块化的好方法，该项目由一个大型Javascript代码库组成，具有许多组件，其中一些组件彼此交互。

最佳答案

有一些警告，CommonJS绝对适合浏览器。 CommonJS模块模式非常好(以我的偏见)，也是为ECMAScript Harmony(计划的JavaScript语言的下一个发行版)提议的模块系统的良好垫脚石。具体来说，Harmony模块将无法访问全局(“窗口”)对象。

有人声称CommonJS模块不适合浏览器的原因是，如果没有服务器端的帮助，就无法通过标记加载它们。例如，假设您有一个Markdown库，可以导出“convertToHTML”函数。然后，您可以制作一个如下所示的模块:

var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
    // do something then call convertToHTML
}

由于某些原因，这不能通过script标签工作(范围未包装，因此convertToHTML将附加到窗口，通常将不需要定义require，并且需要为每个模块分别创建导出)。

具有一点服务器端帮助的客户端库可以允许它通过脚本标签轻松加载。或者，尽管调试体验通常不那么好，但通过XMLHttpRequest加载脚本并执行eval()的客户端库也可以工作。

尽管这也是CommonJS成员之间有争议的辩论主题，但现在是一个相当合理的解决方案，它是RequireJS。使用RequireJS，您可以这样编写模块:

define(function(require, exports, module) {

var convertToHTML = require("markdown").convertToHTML;
exports.mangleSomeText = function() {
    // do something then call convertToHTML
}

});

我们所做的只是在模块周围添加了define()位。 (您可能还可以使服务器轻松完成此操作，因此您甚至无需手动键入define部件)。

我现在已经在几个项目上亲自使用了RequireJS，并发现这是一种无需服务器端即可使用CommonJS模块的简便方法。还有许多其他解决方案，如果您不依赖于运行静态JS文件，则标准的CommonJS模块是一个不错的选择。

(ObDisclaimer:我开始了CommonJS项目，所以我显然有偏见。)

关于javascript - 为什么说CommonJS只适合非浏览器应用程序？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4773298/