Будут ли существующие рамки JavaScript включать CommonJS?

JavaScript-фреймворки, такие как Prototype, jQuery, YUI, MooTools, Dojo и др. все, похоже, нацелены на разработчиков на стороне клиента, с акцентом на то, чтобы обеспечить совместное использование общих шаблонов взаимодействия с пользователем и с меньшим количеством кода.

С появлением серверного JavaScript, эти структуры намерены включить стандарты CommonJS, чтобы включить повторное использование их библиотечных функций для серверного JavaScript или разрешить альтернативные структуры, такие как Node и Narwhal, обрабатывать сервер -защитный вариант использования?

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

Ответ 1

Здесь мой прием (я разработчик YUI):

Кажется, есть два угла на ваш вопрос.

Один из них касается форматов упаковки и повторного использования модулей (CommonJS), а другой - об общей идее JS-библиотек на стороне клиента и их применимости к разработке на стороне сервера.

Я не очень правильно отвечаю на угол упаковки, кроме как сказать, что YUI 3 по своей сути использовал формальную модульную систему для инкапсуляции и доставки кода с первого дня, и он был неотъемлемой частью его дизайна. Предоставление адаптера или шаг сборки для доставки/перевода этих модулей в CommonJS - это то, что мы обсуждали. Другие люди в сообществе YUI, которые участвовали в этой области, могут добавить более ценную информацию.

Во втором углу я могу сказать вам, что сервер является целевой средой первого класса для YUI. Он так же применим на сервере, как и на клиенте. Есть набор модулей, которые имеют смысл только в одном окружении или, конечно же, в другом, но большой фрагмент библиотеки, можно использовать по обеим сторонам забора, и он сознательно построен для этого.

Например, большая часть модулей в YUI предоставляет инфраструктуру и утилиты, которые так же применимы к разработке приложений на сервере, как и на клиенте (Custom Event, Attribute, Base, Intl, Handlebars, IO, YQL, DataType, DataSchema, JSON и т.д.).

Это действительно была цель дизайна с самого начала - это веб-сайт (из-за отсутствия лучшего термина - я имею в виду стек разработки приложений JS/HTML/CSS), а не только библиотеки абстракции DOM, или просто библиотека виджетов.

У Дэви Гласса есть сообщение в блоге с большим содержанием по теме:

http://www.yuiblog.com/blog/2011/11/07/rocking-yui-on-node-js-and-mobile/

Вы также можете проверить 3.5.0 PR:

http://stage.yuilibrary.com/yui/docs/yui/nodejs.html

Ответ 2

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

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

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

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

Ответ 3

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

Поддержка CommonJS не ожидается в jQuery 1.4. Это также не на jQuery 1.5 Roadmap.

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

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

Ответ 4

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

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

Ответ 5

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

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

Все со скидкой, я не уверен, действительно ли что-то осталось. require сантехника?

Ответ 6

Я не могу найти источник, но я слышал, что 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 на клиенте, сервере или и то, и другое.

Ответ 7

Существует случай использования CommonJS вместе с DOM, когда вы говорите о * не * браузерах GUI-приложениях, где доступ к операционной системе не должен быть ограниченным. Например, это было бы очень полезно для разработки приложения, используя Mozilla Chromeless.

Ответ 8

Просто быстрое обновление, похоже, похоже на долгожданный (er, fabled) mootools 2.0, также известный как молоко, aka prime (фамилия для него пока) переместился на CJS.

https://github.com/mootools/prime

Это не значит, что он останется таковым, первая итерация mootools 2.0 появилась почти 2 года назад.