现有的 JavaScript 框架会合并 CommonJS 吗？
JavaScript 框架，如 Prototype、jQuery、YUI、MooTools、Dojo 等。所有这些似乎都针对客户端开发人员，重点是使常见的用户交互模式能够以更少的代码更有效地实现。
随着服务器端 JavaScript 的出现，这些框架是否打算合并 CommonJS 标准以实现服务器端 JavaScript 重用其库函数，或者它们是否允许使用 Node 和 Narwhal 等替代框架来处理服务器端用例？
（我意识到这个问题非常接近可以讨论但无法回答的问题，但我认为 Stack Overflow 社区实际上可以通过具体参考来回答这个问题。）
JavaScript frameworks like Prototype, jQuery, YUI, MooTools, Dojo, et al. all seem to target client-side developers, with the focus on enabling common user interaction patterns to be implemented more efficiently and with less code.
With the emergence of server-side JavaScript, do these frameworks intend to incorporate the CommonJS standards to enable reuse of their library functions for server-side JavaScript, or will they allow alternative frameworks like Node and Narwhal to handle the server-side use case?
(I realize that this question is dangerously close to one which can be discussed but not answered, but I presume the Stack Overflow community can actually answer the question with specific references.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这是我的看法（我是 YUI 开发人员）：
您的问题似乎有两个角度。
一个是关于模块打包和重用格式（CommonJS），另一个是关于客户端 JS 库的一般思想及其对服务器端开发的适用性。
我并不是回答封装角度的合适人选，只是说 YUI 3 从第一天起就本质上使用了正式的模块系统来封装和交付代码，并且它已经成为其设计的一部分。我们一直在讨论提供适配器或构建步骤来将这些模块交付/转换为 CommonJS。 YUI 社区中参与该领域的其他人可能有更多有价值的信息可以在这里添加。
从第二个角度，我可以告诉你，服务器是 YUI 的一流目标环境。它在服务器上和在客户端上都同样适用。当然，有一组模块仅在一个环境或另一个环境中有意义，但是库的很大一部分可以在栅栏的两侧使用，并且它是有意识地构建的。
例如，YUI 中的大部分模块提供了基础设施和实用程序，这些基础设施和实用程序同样适用于服务器上和客户端上的应用程序开发（自定义事件、属性、Base、Intl、Handlebars、IO、YQL、DataType、DataSchema、 JSON 等...）。
这确实是从一开始的设计目标 - 它是一个 Web（由于缺乏更好的术语 - 我指的是 JS/HTML/CSS 技术堆栈）应用程序开发库，而不仅仅是一个 DOM 抽象库，或者只是一个 Widget图书馆。
Dav Glass 有一篇博客文章，其中包含有关该主题的一些精彩内容：
http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/
您还可以查看 3.5.0 PR：
http://stage.yuilibrary.com/yui/docs/yui/nodejs.html
Here's my take (I'm a YUI Developer):
It seems like there are two angles to your question.
One is about module packaging and reuse formats (CommonJS) and the other is about the general idea of client side JS libraries and their applicability to server side development.
I'm not really the right person to answer the packaging angle, other than to say that YUI 3 inherently has used a formal module system for encapsulating and delivering code since day one, and it's been integral to it's design. Providing an adaptor or build step to deliver/translate these modules to CommonJS is something we've been discussing. Other folks in the YUI community who have been involved in this area may have more valuable information to add here.
On the second angle, I can tell you that the server is a first class target environment for YUI. It is just as applicable on the server as on the client. There are a set of modules which only make sense in one environment or the other of course, but a large chunk of the library, can be used on both sides of the fence and it is consciously built to do this.
For example, a large chunk of the modules in YUI provide infrastructure and utilities which are just as applicable to app development on the server as on the client (Custom Event, Attribute, Base, Intl, Handlebars, IO, YQL, DataType, DataSchema, JSON etc...).
That's really been the design goal from the start - It's a web (for lack of a better term - I'm referring to the JS/HTML/CSS technology stack) application development library, not just a DOM Abstraction Library, or just a Widget Library.
Dav Glass has a blog post with some great content on the subject:
http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/
You can also check out the 3.5.0 PRs:
http://stage.yuilibrary.com/yui/docs/yui/nodejs.html
我对 CommonJS 所做的事情的看法是，我们希望能够制作作为同时运行客户端和服务器端的大型系统的一部分的模块。我已经亲自使用过两个不同的客户端 CommonJS 模块加载器，并且它工作得很好。
在浏览器中，您可以使用任何您想要的 DOM 操作库/客户端工具包，这不会真正影响从服务器重用 CommonJS 模块的能力。
在服务器上重用客户端实用程序实际上仍然可以工作。 CommonJS 模块的代码都在闭包中运行，因此每个模块都是独立于其他模块的。基于浏览器的库倾向于使用全局填充的名称空间。到目前为止，服务器上的每个 CommonJS 平台仍然可以以一种或另一种方式使用全局变量。
只要库本身支持没有 DOM 的环境（例如 Rhino），就应该可以使其在典型的 SSJS 环境中工作，尽管不能在 CommonJS 模块中工作。
The way I view what we're doing with CommonJS is that we want to be able to make modules that are part of larger systems that run both client side and server side. I've already personally worked with two different client side CommonJS module loaders, and it works just fine.
In the browser, you can use whatever DOM manipulation library/client side toolkit you want, and that won't really interfere with the ability to also re-use CommonJS modules from the server.
Reusing the client side utilities on the server may actually still work as well. CommonJS modules all have their code run in a closure, so that each module is something independent of the other modules. Browser-based libraries tend to work with namespaces that are populated globally. Thus far, every CommonJS platform on the server can still use globals in one fashion or another.
As long as the library itself is made to support environments without a DOM (such as Rhino), it should be possible to make it work in a typical SSJS environment, albeit not in CommonJS-modules.
由于大多数这些库专门针对 DOM，并且旨在简化浏览器 API 和跨浏览器问题，因此我不确定这会带来什么优势。
预计 jQuery 1.4 中不会支持 CommonJS。它也不在 jQuery 1.5 路线图上。
Dojo 确实努力变得更加包罗万象，并且有一个关于在 Dojo 中添加对 CommonJS 的支持 但它被标记为未来。
一般来说，我不会指望它。
Since most of those libraries specifically target the DOM and are designed to simplify browser APIs and cross-browser issues, I'm not sure what advantage this would give.
CommonJS support is not expected in jQuery 1.4. It is also not on the jQuery 1.5 Roadmap.
Dojo does endeavor to be more all-encompassing and has an issue open about adding support for CommonJS in Dojo but it is marked as future.
In general, I wouldn't count on it.
正如大家已经说过的，大多数 JavaScript 库大部分都是 DOM 的包装器。
但是，我不会考虑将 CommonJS 仅用于服务器端。我认为它在客户端会有一席之地，特别是当 Javascript 朝着改进的安全模型发展时，该模型将大大受益于 CommonJS 的模块化方法。
Like everyone has already said, most JavaScript libraries are wrappers on the DOM for the most part.
However, I would not consider CommonJS only for server side. I think there will be a place for it on the client side, especially as Javascript moves towards an improved security model that would greatly benefit from a CommonJS approach to modularization.
大多数 CommonJS API 都是面向服务器的功能，您根本无法在浏览器 JS 中实现。当前模块中，
io、fs、system、sockets和workerplus JSGI 等就其基本性质而言是无法实现的。encodings需要大量的数据表，您不想将这些数据表构建到库中（除了您已经可以很好地处理的基本内置编码）。其他功能无法得到支持，仅仅是因为它们需要诸如 getter/setter 之类的语言功能，但由于支持较差，这些功能尚无法在浏览器中使用。都打折了，不知道还有没有剩下的。
需要管道？Most of the CommonJS APIs are server-oriented features you simply wouldn't be able to implement in browser JS. Of the current modules,
io,fs,system,socketsandworkerplus JSGI et al are unimplementable by their basic nature.encodingswould need enormous data tables that you wouldn't want to build into a library (except for the basic built-in encodings that you can already handle quite well as it is). Other features can't be supported simply because they would need language features like getter/setters that can't be used in the browser yet due to poor support.All those discounted, I'm not sure if there's really anything much left. The
requireplumbing?我找不到源代码，但我听说 jQuery 1.4 将把所有插件打包为 CommonJS 包（http://wiki.commonjs.org/wiki/Packages/1.0）。这并不意味着它们都将是 CommonJS 模块，但这是朝着正确方向迈出的一步，也是事情正在朝着这个方向发展的标志。
有一个 Narwhal 包实现了 Prototype 的子集：http://github。 com/smith/prototype-asp/tree/narwhal-global。它还可以在其他 SSJS 平台上运行。
Dojo Trac 上有一张票证可供添加 CommonJS 模块支持： http://bugs.dojotoolkit.org/ Ticket/9349
SproutCore，这个拥有 Bespin 和 MobileMe 等的框架，也将支持 CommonJS： http ://wiki.sproutcore.com/Tiki 和卡布奇诺咖啡制造商 280 North 雇用了一些主要的 Narwhal 开发人员。
因此，不同框架之间以及客户端和服务器之间仍然存在很多碎片，但现在还为时过早，事情正在朝着正确的方向发展。我预测在未来的某个时候，所有主要的 JS 框架都将在客户端、服务器或两者上提供一些 CommonJS 支持。
I can't find the source, but I've heard jQuery 1.4 is going to have all plugins in its packaged as CommonJS packages (http://wiki.commonjs.org/wiki/Packages/1.0). This doesn't mean they will all be CommonJS modules, but it's a step in the right direction and a sign that things are moving that way.
There is a Narwhal package that implements a subset of Prototype: http://github.com/smith/prototype-asp/tree/narwhal-global. It also runs on other SSJS platforms.
There's a ticket open on the Dojo Trac to add CommonJS Module support: http://bugs.dojotoolkit.org/ticket/9349
SproutCore, the framework that has Bespin and MobileMe, among others, will also support CommonJS: http://wiki.sproutcore.com/Tiki, and 280 North, the makers of Cappuccino, employ some of the main Narwhal developers.
So, there's still lots of fragmentation between different frameworks and between client and server, but it's early and things are moving in the right direction. I predict sometime in the future all major JS frameworks will have some CommonJS support on the client, server, or both.
当您谈论*非*浏览器 GUI 应用程序时，可以将 CommonJS 与 DOM 一起使用，其中操作系统访问不需要受到限制。例如，这对于使用 Mozilla 无铬。
There is a case for using CommonJS along with the DOM when you're talking about *non-*browser GUI applications, where operating system access would not need to be as restricted. For example, this would be very useful for developing an application using Mozilla Chromeless.
只是快速更新一下，看起来期待已久的（呃，传说中的）mootools 2.0，又名 milk，又名 prime（现在的姓氏）已经转移到了 CJS。
https://github.com/mootools/prime
这并不是说它将保持原样， mootools 2.0 的第一次迭代大约是在两年前出现的。
Just a quick update to say, looks like the long awaited (er, fabled) mootools 2.0, aka milk, aka prime (last name for it for now) has moved over to CJS.
https://github.com/mootools/prime
this is not to say it will remain as such, the first iteration of mootools 2.0 came about nearly 2 years ago.