JavaScript 框架，如 Prototype、jQuery、YUI、MooTools、Dojo 等。所有这些似乎都针对客户端开发人员，重点是使常见的用户交互模式能够更有效地实现并使用更少的代码。
随着服务器端 JavaScript 的出现，这些框架是否打算合并 CommonJS 标准以实现服务器端 JavaScript 库函数的重用，或者它们是否允许 Node 和 Narwhal 等替代框架来处理服务器端用例？
（我意识到这个问题非常接近一个可以讨论但无法回答的问题，但我认为 Stack Overflow 社区实际上可以通过具体参考来回答这个问题。）
这是我的看法（我是 YUI 开发人员）：
您的问题似乎有两个角度。
一个是关于模块打包和重用格式（CommonJS），另一个是关于客户端 JS 库的一般概念及其对服务器端开发的适用性。
我不是真正适合回答封装角度的人，除了说 YUI 3 从一开始就固有地使用正式的模块系统来封装和交付代码，并且它已经融入了它的设计。提供适配器或构建步骤以将这些模块交付/翻译到 CommonJS 是我们一直在讨论的事情。YUI 社区中参与该领域的其他人可能会在此处添加更多有价值的信息。
在第二个角度，我可以告诉你，服务器是 YUI 的一流目标环境。它在服务器上和在客户端上一样适用。当然，有一组模块只在一个环境或另一个环境中有意义，但是库的很大一部分，可以在栅栏的两侧使用，并且有意识地构建它来做到这一点。
例如，YUI 中的大部分模块提供了基础设施和实用程序，这些基础设施和实用程序同样适用于服务器上的应用程序开发（自定义事件、属性、基础、国际、把手、IO、YQL、DataType、DataSchema、 JSON等...）。
这确实是从一开始的设计目标——它是一个网络（因为没有更好的术语——我指的是 JS/HTML/CSS 技术堆栈）应用程序开发库，而不仅仅是一个 DOM 抽象库，或者只是一个小部件图书馆。
Dav Glass 有一篇博客文章，其中包含一些关于该主题的精彩内容：
http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/
您还可以查看 3.5.0 PR：
我看待我们正在使用 CommonJS 所做的事情的方式是，我们希望能够制作作为运行客户端和服务器端的更大系统的一部分的模块。我已经亲自使用过两个不同的客户端 CommonJS 模块加载器，而且效果很好。
在浏览器中，您可以使用任何您想要的 DOM 操作库/客户端工具包，这不会真正影响从服务器重用 CommonJS 模块的能力。
在服务器上重用客户端实用程序实际上可能仍然有效。CommonJS 模块都在闭包中运行它们的代码，因此每个模块都是独立于其他模块的东西。基于浏览器的库倾向于使用全局填充的命名空间。到目前为止，服务器上的每个 CommonJS 平台仍然可以以一种或另一种方式使用全局变量。
只要库本身支持没有 DOM 的环境（例如 Rhino），就应该可以使其在典型的 SSJS 环境中工作，尽管不是在 CommonJS 模块中。
由于这些库中的大多数专门针对 DOM，并且旨在简化浏览器 API 和跨浏览器问题，因此我不确定这会带来什么优势。
在 jQuery 1.4 中不期望 CommonJS 支持。它也不在jQuery 1.5 Roadmap上。
Dojo 确实努力做到包罗万象，并且有一个关于在 Dojo 中添加对 CommonJS 的支持的问题，但它被标记为future。
一般来说，我不会指望它。
我找不到源代码，但我听说 jQuery 1.4 将把所有插件打包为 CommonJS 包（http://wiki.commonjs.org/wiki/Packages/1.0）。这并不意味着它们都将成为 CommonJS 模块，但这是朝着正确方向迈出的一步，并且表明事情正在朝着这个方向发展。
有一个实现 Prototype 子集的 Narwhal 包：http: //github.com/smith/prototype-asp/tree/narwhal-global。它还可以在其他 SSJS 平台上运行。
Dojo Trac 上有一张票可以添加 CommonJS 模块支持：http ://bugs.dojotoolkit.org/ticket/9349
包含 Bespin 和 MobileMe 等的框架 SproutCore 也将支持 CommonJS：http ://wiki.sproutcore.com/Tiki ，Cappuccino 的制造商 280 North 雇佣了一些主要的 Narwhal 开发人员。
所以，不同框架之间以及客户端和服务器之间仍然存在很多碎片，但现在还为时过早，事情正在朝着正确的方向发展。我预测在未来的某个时候，所有主要的 JS 框架都会在客户端、服务器或两者上都有一些 CommonJS 支持。
就像大家已经说过的那样，大多数 JavaScript 库大部分都是 DOM 的包装器。
但是，我不会仅将 CommonJS 用于服务器端。我认为它会在客户端占有一席之地，尤其是当 Javascript 朝着改进的安全模型发展时，该模型将极大地受益于 CommonJS 的模块化方法。
大多数 CommonJS API 都是面向服务器的功能，您根本无法在浏览器 JS 中实现。在当前的模块中，io、fs、system和socketsplus workerJSGI 等由于其基本性质而无法实现。
encodings将需要您不想构建到库中的大量数据表（除了您已经可以很好地处理的基本内置编码）。其他特性不能被支持，仅仅因为它们需要像 getter/setter 这样的语言特性，但由于支持不佳，这些特性还不能在浏览器中使用。
所有这些都打折了，我不确定是否真的还有很多东西。require水管？
当您谈论 *non-*browser GUI 应用程序时，有一种将 CommonJS 与 DOM 一起使用的情况，其中操作系统访问不需要受到限制。例如，这对于使用Mozilla Chromeless开发应用程序非常有用。
只是一个快速的更新，看起来期待已久的（呃，传说中的）mootools 2.0，又名牛奶，又名素数（现在的姓氏）已经转移到 CJS。
https://github.com/mootools/prime
这并不是说它将保持不变，mootools 2.0 的第一次迭代大约在 2 年前出现。