Prototype、jQuery、YUI、MooTools、Dojo などの JavaScript フレームワーク。いずれもクライアント側の開発者をターゲットにしているようで、一般的なユーザー インタラクション パターンをより効率的に、より少ないコードで実装できるようにすることに重点が置かれています。
サーバーサイド JavaScript の出現により、これらのフレームワークは CommonJS 標準を組み込んでサーバーサイド JavaScript のライブラリ関数を再利用できるようにするつもりですか、それとも Node や Narwhal などの代替フレームワークでサーバーサイドのユースケースを処理できるようにする予定ですか?
（この質問は、議論できるが答えられない質問に危険なほど近いことを認識していますが、スタックオーバーフローコミュニティは実際に特定の参照で質問に答えることができると思います。）
これが私の見解です（私はYUI開発者です）：
あなたの質問には2つの角度があるようです。
1つはモジュールのパッケージ化と再利用形式（CommonJS）に関するもので、もう1つはクライアント側のJSライブラリの一般的な考え方とサーバー側の開発への適用性に関するものです。
YUI 3は、コードのカプセル化と配信に最初から正式なモジュールシステムを本質的に使用しており、その設計に不可欠であると言う以外は、私はパッケージングの角度に答えるのに適切な人物ではありません。これらのモジュールをCommonJSに配信/変換するためのアダプターまたはビルド・ステップを提供することは、私たちが議論してきたことです。この分野に携わってきたYUIコミュニティの他の人々は、ここに追加するより価値のある情報を持っているかもしれません。
2番目の角度では、サーバーはYUIのファーストクラスのターゲット環境であると言えます。これは、クライアントと同様にサーバーにも適用できます。もちろん、どちらかの環境でのみ意味のあるモジュールのセットがありますが、ライブラリの大部分はフェンスの両側で使用でき、これを行うために意識的に構築されています。
たとえば、YUIのモジュールの大部分は、クライアントと同様にサーバーでのアプリ開発に適用できるインフラストラクチャとユーティリティを提供します（カスタムイベント、属性、ベース、国際、ハンドルバー、IO、YQL、DataType、DataSchema、 JSONなど...）。
それは最初から本当に設計目標でした-それはWeb（より良い用語がないため-私はJS / HTML / CSSテクノロジースタックを指します）アプリケーション開発ライブラリであり、DOM抽象化ライブラリやウィジェットだけではありませんとしょうかん。
Dav Glassには、このテーマに関するすばらしいコンテンツを含むブログ投稿があります。
http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/
3.5.0PRを確認することもできます。
私たちが CommonJS で行っていることは、クライアント側とサーバー側の両方を実行する大規模なシステムの一部であるモジュールを作成できるようにしたいということです。私はすでに 2 つの異なるクライアント側の CommonJS モジュール ローダーを個人的に使用してきましたが、問題なく動作します。
ブラウザーでは、好きな DOM 操作ライブラリー/クライアント側ツールキットを使用できますが、サーバーから CommonJS モジュールを再利用する機能を実際に妨げることはありません。
サーバーでクライアント側のユーティリティを再利用しても、実際には機能する場合があります。CommonJS モジュールはすべてクロージャーでコードを実行するため、各モジュールは他のモジュールから独立しています。ブラウザー ベースのライブラリは、グローバルに設定された名前空間で動作する傾向があります。これまでのところ、サーバー上のすべての CommonJS プラットフォームは、何らかの方法で引き続きグローバルを使用できます。
ライブラリ自体が DOM のない環境 (Rhino など) をサポートするように作成されている限り、CommonJS モジュールではなくても、典型的な SSJS 環境で動作させることができるはずです。
これらのライブラリのほとんどは特に DOM を対象としており、ブラウザ API とクロスブラウザの問題を簡素化するように設計されているため、これがどのような利点をもたらすかはわかりません。
jQuery 1.4 では、CommonJS のサポートは想定されていません。また、jQuery 1.5 ロードマップにもありません。
Dojo はより包括的なものになるように努力しており、CommonJS のサポートを Dojo に追加することに関して未解決の問題がありますが、それはfutureとマークされています。
一般的に、私はそれを当てにしないでしょう。
誰もが既に言ったように、ほとんどの JavaScript ライブラリは大部分が DOM のラッパーです。
ただし、CommonJS をサーバー側だけに限定することは考慮しません。特に Javascript が改善されたセキュリティ モデルに移行するにつれて、CommonJS のモジュール化アプローチから大きなメリットが得られるため、クライアント側にその場所があると思います。
CommonJS API のほとんどは、ブラウザー JS では実装できないサーバー指向の機能です。現在のモジュールのうち、io、fs、system、socketsおよびworkerJSGI などは、基本的な性質上実装できません。
encodingsライブラリに組み込みたくない膨大なデータ テーブルが必要になります (ただし、そのままで十分に処理できる基本的な組み込みエンコーディングは除きます)。他の機能は、サポートが不十分なためにブラウザーでまだ使用できない getter/setter などの言語機能が必要なため、単にサポートできません。
割引されたものはすべて、本当に残っているものがあるかどうかはわかりません。配管require？
ソースが見つかりませんが、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 プラットフォームでも実行されます。
CommonJS モジュールのサポートを追加するためのチケットが Dojo Trac で公開されています: http://bugs.dojotoolkit.org/ticket/9349
Bespin や MobileMe などを備えたフレームワークである SproutCore も、CommonJS をサポートします: http://wiki.sproutcore.com/Tikiと、Cappuccino のメーカーである 280 North は、主要な Narwhal 開発者の何人かを雇用しています。
したがって、異なるフレームワーク間およびクライアントとサーバー間にはまだ多くの断片化がありますが、それはまだ早い段階であり、物事は正しい方向に進んでいます. 将来的には、すべての主要な JS フレームワークが、クライアント、サーバー、またはその両方で CommonJS をサポートするようになると予測しています。
簡単なアップデートを言うと、待望の (えー、伝説の) mootools 2.0、別名ミルク、別名プライム (今のところ姓) が CJS に移行したようです。
https://github.com/mootools/prime
mootools 2.0 の最初のイテレーションは約 2 年前に登場しました。
オペレーティング システムのアクセスをそれほど制限する必要のない *非*ブラウザ GUI アプリケーションについて話している場合、DOM と一緒に CommonJS を使用する場合があります。たとえば、これはMozilla Chromelessを使用してアプリケーションを開発する場合に非常に役立ちます。