JavaScript框架，如Prototype，jQuery，YUI，MooTools，Dojo等。都似乎针对客户端开发人员，重点在于使普通用户交互模式能够更有效地实施，而代码更少。现有的JavaScript框架是否包含CommonJS？
随着服务器端JavaScript的出现，这些框架是否打算整合CommonJS标准，以便为服务器端JavaScript重用其库函数，还是允许像Node和Narwhal这样的替代框架来处理服务器端JavaScript，边用例？
（我意识到这个问题，正在危险地接近一个可以讨论，但没有回答，但我相信堆栈溢出的社会能真正回答具体参考的问题。）
由于大多数这些库的具体以DOM为目标，旨在简化浏览器API和跨浏览器问题，我不确定这会带来什么优势。
CommonJS支持不在jQuery 1.4中。它也不在jQuery 1.5 Roadmap上。
道场确实努力变得更加全面，并有一个问题开放adding support for CommonJS in Dojo但它被标记为未来。
一般来说，我不会指望它。
与大家已经说过的一样，大多数JavaScript库大部分都是在DOM上进行封装。
但是，我不认为CommonJS只适用于服务器端。我认为在客户端会有一个地方，特别是当Javascript正在朝着一种改进的安全模式发展时，这种模式将大大受益于CommonJS模块化方法。
大多数CommonJS API都是面向服务器的功能，您根本无法在浏览器JS中实现这些功能。在当前的模块中，io,fs,system,sockets和worker加上JSGI等的基本特性是不可实现的。
encodings将需要庞大的数据表，您不想将其构建到库中（除了基本的内置编码，您已经可以很好地处理它）。其他功能不能被简单地支持，因为它们需要像getter/setter这样的语言功能，这些功能由于支持不佳而无法在浏览器中使用。
所有这些打折，我不知道是否有什么更多的剩余。 require水暖？
对我来说，一点是能够在客户端和服务器之间共享业务逻辑（模型对象及其验证等）。这几乎只需要模块支持。 你肯定是正确的，大多数标准不适用于浏览器。 – 2010-01-05 12:49:27
我查看我们在CommonJS上所做的工作的方式是我们希望能够使模块成为运行客户端和服务器端的大型系统的一部分。我已经亲自与两个不同的客户端CommonJS模块加载器一起工作，并且它工作得很好。
在浏览器中，您可以使用任何您想要的DOM操作库/客户端工具包，这并不会影响从服务器重新使用CommonJS模块的能力。
重新使用服务器上的客户端实用程序可能实际上仍然工作。 CommonJS模块的代码都在闭包中运行，因此每个模块都独立于其他模块。基于浏览器的库倾向于使用全局填充的名称空间。到目前为止，服务器上的每个CommonJS平台仍然可以以某种方式使用全局变量。
只要库本身支持没有DOM的环境（比如Rhino），应该可以使其在典型的SSJS环境中工作，尽管不在CommonJS模块中。
我找不到源代码，但我听说jQuery 1.4将打包为CommonJS包（http://wiki.commonjs.org/wiki/Packages/1.0）。这并不意味着它们都将成为CommonJS模块，但这是朝着正确方向迈出的一步，并且表明事情正在以这种方式发展。
有一个Narwhal包实现了原型的一个子集：http://github.com/smith/prototype-asp/tree/narwhal-global。它也运行在其他SSJS平台上。
有一个在道场Trac的开放增添CommonJS的模块支持票：http://bugs.dojotoolkit.org/ticket/9349
SproutCore的，有贝斯平和MobileMe的框架，除其他外，还将支持CommonJS的：http://wiki.sproutcore.com/Tiki和280北的制造商卡布奇诺，雇用一些主要的纳瓦尔开发人员。
因此，不同框架之间以及客户端和服务器之间仍然存在很多碎片化现象，但时间早，事情正朝着正确的方向发展。我预测在未来的某个时候，所有主要的JS框架都会在客户端，服务器或两者上都有一些CommonJS支持。
http://groups.google.com/group/commonjs/browse_thread/thread/39dcdede35edcddd是您可能引用的来源。 jQuery 1.4和1.4.1已经在没有任何CommonJS结构的情况下发布 - 但运行jQuery插件网站的团队似乎已经把他们的重要性放在CommonJS的包装上。 – 2010-02-08 03:35:57
当您谈论*非*浏览器GUI应用程序时，有一种情况是使用CommonJS以及DOM，其中操作系统访问不需要受限制。例如，这对于使用MozillaChromeless开发应用程序非常有用。
只是一个快速更新说，看起来像期待已久的（呃，寓言）mootools 2.0，又名牛奶，又名素（现在的姓氏）已转移到CJS。
https://github.com/mootools/prime
这并不是说将保持正因为如此，mootools的2.0的第一次迭代是约近2年前。
这里是我采取的（我是一个YUI开发者）：
好像有两个角度来你的问题。
一个是关于模块封装和重用格式（CommonJS），另一个是关于客户端JS库的一般概念及其对服务器端开发的适用性。
我不是真正适合回答包装角度的人，除了说YUI 3从第一天开始已经使用正式的模块系统来封装和交付代码，并且它已经成为其设计的组成部分。提供适配器或构建步骤来将这些模块交付/转换为CommonJS是我们一直在讨论的。 YUI社区的其他人员可能会在这里添加更多有价值的信息。
在第二个角度，我可以告诉你，服务器是YUI的第一类目标环境。它和服务器上的一样适用于客户端。有一套模块只能在一个环境或另一个环境中才有意义，但图书馆的一大块可用于围栏的两侧，并且有意识地建立这样的模块。例如，YUI中的大块模块提供的基础结构和实用程序与服务器上的应用程序开发一样适用于客户端（自定义事件，属性，基础，Intl，把手，IO，YQL， DataType，DataSchema，JSON等）。这是一个真正从一开始就是设计目标 - 它是一个Web（缺乏更好的术语 - 我指的是JS/HTML/CSS技术堆栈）应用程序开发库，而不仅仅是一个DOM抽象库，或者只是一个Widget库。
DAV玻璃有一个博客帖子关于这个问题的一些伟大的内容：
http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/
您还可以检查出3.5.0的PR：
你提到的库全部包装DOM api。我不明白在服务器上重新使用这些库的问题，当服务器没有像浏览器提供的那样合并实际的DOM时。我可能没有足够的想象力？ – 2010-01-04 15:03:02
@Crescent Fresh你是对的，这将是无用的，但也许他喜欢使用像jQuery.each这样的函数？ – JCasso 2010-01-04 15:08:26
MooTools的Native组件增加了一些内置的构造函数，使它们增加了与DOM无关的增加的功能（http://github.com/mootools/mootools-core/tree/master/Source/Native/）;我想知道把这类东西带入SSJS。 – 2010-01-04 15:09:25