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