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

发布于 2024-10-13 20:22:14 字数 133 浏览 2 评论 0原文

为什么不使用它作为 Javascript 的通用组件模式，包括浏览器执行的 Javascript？

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

怎言笑 2024-10-20 20:22:14

CommonJS 绝对适合浏览器，但有一些注意事项。 CommonJS 模块模式非常好（在我看来），并且也是为 ECMAScript Harmony（计划的 JavaScript 语言的下一个版本）提出的模块系统的一个很好的垫脚石。具体来说，Harmony 模块将无权访问全局（“窗口”）对象。

有些人声称 CommonJS 模块不适合浏览器的原因是它们无法通过

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

由于某些原因，这无法通过脚本标记工作（范围未包装，因此 ConvertToHTML 将附加到窗口，通常不会定义 require 并且导出需要为每个模块单独创建）。

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

目前，一个相当合理的解决方案是 RequireJS，尽管它也是 CommonJS 成员之间争论的主题。使用 RequireJS，您可以像这样编写模块：

define(function(require, exports, module) {

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

});

我们所做的就是在模块周围添加 Define() 位。（您也可以让服务器很容易地做到这一点，这样您甚至不需要手动键入定义部分）。

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

（Ob免责声明：我启动了 CommonJS 项目，所以我显然有偏见。）

CommonJS is definitely suitable for the browser, with some caveats. The CommonJS module pattern is quite nice (in my biased opinion), and is also a good stepping stone to the module system proposed for ECMAScript Harmony (the planned next release of the JavaScript language). Specifically, Harmony modules won't have access to the global ("window") object.

The reason that some people claim CommonJS modules are not suitable for the browser is that they can't be loaded via a <script> tag without some server-side assistance. For example, imagine you have a markdown library that exports a "convertToHTML" function. You could then make a module that looks like this:

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

This doesn't work via a script tag for a few reasons (the scope isn't wrapped, so convertToHTML would get attached to window, require wouldn't typically be defined and exports needs to be created separately for each module).

A client side library with a tiny bit of server side help could allow this to load via script tags easily. Or, a client side library that loads the script via XMLHttpRequest and does an eval() would also work, though the debugging experience is often not as good.

A fairly reasonable solution right now, though one that is also the subject of contentious debate among CommonJS members, is RequireJS. Using RequireJS, you can write your module like this:

define(function(require, exports, module) {

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

});

All we did was add that define() bit around the module. (You could likely make a server do that pretty easily as well, so that you don't even need to manually type the define part).

I've personally used RequireJS on a couple of projects now and find it an easy way to make use of CommonJS modules without a server-side bit. There are many other solutions and if you aren't reliant on running static JS files, standard CommonJS modules are a great way to go.

(ObDisclaimer: I started the CommonJS project, so I am clearly biased.)

回复收藏 0 原文

~没有更多了~