Существующие платформы JavaScript включат CommonJS?

Большинство API CommonJS - это серверно-ориентированные функции, которые вы просто не смогли бы реализовать в браузере JS. Из текущих модулей io, fs, system, sockets и worker плюс JSGI и др. по своей базовой природе не реализуются.

кодировки потребовали бы огромных таблиц данных, которые вы не захотели бы встроить в библиотеку (за исключением основных встроенных кодировок, с которыми вы и так уже можете справиться). Другие возможности не могут быть поддержаны просто потому, что им потребуются такие языковые возможности, как getter/setters, которые пока не могут быть использованы в браузере из-за плохой поддержки.

Все эти скидки, я не уверен, что на самом деле осталось что-нибудь особенное. требуется водопровод?

Так как большинство из этих библиотек специально ориентированы на DOM и предназначены для упрощения API браузера и межбраузерных проблем, я не уверен, какое это даст преимущество.

Поддержка CommonJS не ожидается в jQuery 1.4. Его также нет в дорожной карте jQuery 1.5 .

Dojo стремится быть более всеобъемлющим и имеет открытую проблему о добавлении поддержки CommonJS в Dojo , но он отмечен как future.

В общем, я бы не стал на это рассчитывать.

] Как все уже говорили, большинство библиотек JavaScript по большей части являются обёртками на DOM[

] [] Однако [] я бы не стал рассматривать CommonJS только для серверной стороны. Я думаю, что место для этого будет на стороне клиента, тем более, что Javascript движется в сторону улучшенной модели безопасности, которая значительно выиграет от подхода CommonJS к модуляризации.[

Я думаю, что мы делаем с CommonJS, что мы хотим иметь возможность делать модули, которые являются частью больших систем, которые работают как на стороне клиента, так и на стороне сервера. Я уже лично работал с двумя разными загрузчиками модулей на стороне клиента CommonJS, и он работает просто отлично.

В браузере вы можете использовать любую библиотеку манипулирования DOM/инструментарий на стороне клиента, и это не будет мешать возможности повторного использования модулей CommonJS с сервера.

Повторное использование утилит клиентской стороны на сервере может на самом деле также работать. Все модули CommonJS работают в закрытом режиме, так что каждый модуль является чем-то независимым от других модулей. Браузерные библиотеки, как правило, работают с пространствами имен, которые заполнены глобально. До сих пор каждая платформа CommonJS на сервере может так или иначе использовать глобусы.

До тех пор, пока сама библиотека сделана для поддержки окружения без DOM (например, Rhino), должна быть возможность заставить её работать в типичном SSJS окружении, хотя и не в CommonJS-модулях.

Я не могу найти исходники, но я слышал, что 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: http://bugs.dojotoolkit.org/ticket/9349

SproutCore, фреймворк с Bespin и MobileMe, среди прочего, также будет поддерживать CommonJS: http://wiki.sproutcore.com/Tiki, а 280 North, производители Cappuccino, нанимают некоторых из основных разработчиков Narwhal.

Итак, между различными фреймворками и между клиентом и сервером всё ещё много фрагментации, но это рано и всё движется в правильном направлении. Я предсказываю, что когда-нибудь в будущем все основные JS фреймворки будут иметь поддержку CommonJS на клиенте, сервере или на обоих.