现有的JavaScript框架是否包含CommonJS？

JavaScript框架，如Prototype，jQuery，YUI，MooTools，Dojo等。所有这些似乎都以客户端开发人员为目标，重点是使用更少的代码更有效地实现通用用户交互模式。

随着服务器端JavaScript的出现，这些框架是否打算采用CommonJS标准来实现其库函数重用于服务器端JavaScript，还是允许其他框架（如Node和Narwhal）处理服务器端用例？

（我意识到这个问题危险地接近可以讨论但没有回答的问题，但我认为Stack Overflow社区实际上可以用特定的引用回答这个问题。）

这是我的看法（我是YUI开发人员）：

你的问题似乎有两个角度。

一个是关于模块打包和重用格式（CommonJS），另一个是关于客户端JS库的一般概念及其对服务器端开发的适用性。

我不是回答包装角度的合适人选，除了说YUI 3从第一天起就已经使用了正式的模块系统来封装和交付代码，而且它已经成为它设计的一部分。提供适配器或构建步骤以将这些模块传递/转换为CommonJS是我们一直在讨论的问题。 YUI社区中参与此领域的其他人可能会在此处添加更多有价值的信息。

在第二个角度，我可以告诉你服务器是YUI的第一类目标环境。它在服务器上和在客户端上一样适用。有一组模块只在一个环境或其他环境中有意义，但是大部分库可以在栅栏的两侧使用，并且有意识地建立这样做。

例如，YUI中的大块模块提供的基础结构和实用程序与客户端上的应用程序开发一样适用（自定义事件，属性，基础，Intl，Handlebars，IO，YQL，DataType，DataSchema， JSON等……）。

这从一开始就是设计目标 – 它是一个网络（缺乏一个更好的术语 – 我指的是JS / HTML / CSS技术堆栈）应用程序开发库，而不仅仅是一个DOM抽象库，或者只是一个Widget图书馆。

戴维格拉有一篇博客文章，其中有一些关于这个主题的精彩内容

您还可以查看3.5.0 PR：

我查看我们使用CommonJS做的事情的方式是我们希望能够创建属于运行客户端和服务器端的大型系统的模块。我已经亲自使用过两个不同的客户端CommonJS模块加载器，它工作得很好。

在浏览器中，您可以使用您想要的任何DOM操作库/客户端工具包，这不会真正干扰从服务器重用CommonJS模块的能力。

重用服务器上的客户端实用程序实际上仍然可以正常工作。 CommonJS模块的代码都在闭包中运行，因此每个模块都独立于其他模块。基于浏览器的库倾向于使用全局填充的命名空间。到目前为止，服务器上的每个CommonJS平台仍然可以以某种方式使用全局变量。

只要库本身支持没有DOM的环境（例如Rhino），就应该可以使它在典型的SSJS环境中工作，尽管不在CommonJS模块中。

由于大多数这些库专门针对DOM而且旨在简化浏览器API和跨浏览器问题，因此我不确定这会带来什么好处。

jQuery 1.4中不支持CommonJS支持。它也不在jQuery 1.5路线图上。

Dojo确实努力做到更加全面，并且在Dojo中添加对CommonJS的支持有一个问题，但它被标记为未来。

一般来说，我不会指望它。

就像每个人都已经说过的那样，大多数JavaScript库大部分都是DOM上的包装器。

但是，我不会仅考虑服务器端的CommonJS。我认为在客户端会有一个地方，特别是随着Javascript走向改进的安全模型，这将大大受益于CommonJS模块化方法。

大多数CommonJS API都是面向服务器的function，您无法在浏览器JS中实现这些function。在当前的模块中， io ， fs ， system ， sockets和worker以及JSGI等人的基本性质无法实现。

encodings需要大量的数据表，你不希望将它们构建到一个库中（除了你已经可以处理得很好的基本内置编码）。其他function不能简单地支持，因为它们需要语言function，如getter / setter，由于支持不佳而无法在浏览器中使用。

所有那些打折，我不确定是否还剩下任何东西。 require管道？

我找不到源代码，但我听说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 Module支持的门票： http ： //bugs.dojotoolkit.org/ticket/9349

具有Bespin和MobileMe的框架SproutCore也将支持CommonJS： http ：//wiki.sproutcore.com/Tiki，Cappuccino的制造商280 North雇佣了一些主要的Narwhal开发人员。

因此，不同的框架之间以及客户端和服务器之间仍然存在很多碎片，但它是早期的，并且事情正朝着正确的方向发展。我预测未来某个时候所有主要的JS框架都会在客户端，服务器或两者上都有一些CommonJS支持。

当您谈论*非*浏览器GUI应用程序时，有一种情况可以使用CommonJS和DOM，其中操作系统访问不需要受限制。例如，这对于使用Mozilla Chromeless开发应用程序非常有用。

只是一个快速更新，看起来像期待已久的（呃，传说中的）mootools 2.0，又名牛奶，又名素数（现在它的姓氏）已经转移到了CJS。

这并不是说它将保持这样，大约2年前，mootools 2.0的第一次迭代出现了。