Сравнение способов создания тулчейна: JS-модули/загрузчик/сборка

В процессе оценки различных подходов, доступных разработчикам для использования javascript-модулей, загрузчиков модулей и инструментов сборки, я хотел бы получить несколько советов о том, какие инструменты вы используете и почему.

В настоящее время я ищу что-то, что может:
-поощрять модульный код
-разрешать добавлять функции в зависимости от необходимости в данный модуль [подумайте о миксинах/наследовании]
-создавать BUILD, который содержит версия для разработки и, как минимум, производственная версия с разными уровнями (скажем, мне нужен слой [скрипт], который содержит мой загрузочный код, модули 1, 2 и 3; а затем еще один слой, который содержит модули 4, 5 и 6 . Таким образом, я могу отложить загрузку кода в зависимости от того, что на самом деле происходит в приложении.)
-Работа [при создании для производства] в сценарии с чрезвычайно низкой пропускной способностью, со скоростью xfer 1 кбит/с и высокой задержкой (в худшем случае). мобильное соединение через GPRS, чтобы получить изображение).

Я видел следующее: Использование наследования прототипов, например:

myNS.thing = function(){};
myns.thing.prototype = {
    something: "foo"
}

Который можно построить, просто взяв содержимое этого скрипта и добавив его к следующему, который нужно включить в пакет, оптимизированный для производства, как один скрипт. Загрузчики в этом случае представляют собой простые инъекции тегов скрипта/eval или аналогичные, основанные на известном файле.

Я также видел другие подходы, такие как:

function(){
    return function(){
        something: "foo"
    }
}();

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

В обоих этих подходах отсутствуют зависимости.

Тогда у нас есть AMD:

define("mymodule", ["dep1"], function(dep1){
    return {something: dep1}
});

Некоторых может оттолкнуть его отступ и его «церемония», но все же он довольно эффективен, компилятор закрытия Google знает об этом изначально, он знает о зависимостях и, похоже, получил широкое распространение по всем направлениям. Для него доступно множество загрузчиков модулей (https://docs.google.com/spreadsheet/ccc?key=0Aqln2akPWiMIdERkY3J2OXdOUVJDTkNSQ2ZsV3hoWVE#gid=2), а также довольно много инструментов сборки.

Какие еще варианты вы знаете или видели в производстве?

Как уже было сказано, меня интересует сочетание синтаксиса кода, инструментов загрузки и инструментов сборки. Эти три должны существовать и правильно работать вместе. Остальное - академические упражнения, которые мне не интересны.


person DLeonardi    schedule 11.01.2013    source источник


Ответы (2)


Я лично использую RequireJS, решение AMD. Если я подготовлю быстрое доказательство концепции, я не буду настраивать это, но наиболее распространенные решения для исходного/деп-мэппинга, которые я знаю сейчас, включают:

  • ТребоватьJS
  • CommonJS
  • Закрытие Google
  • YepNope (условный загрузчик, можно использовать в сочетании с другими)

Я запустил шаблон, который использует Require в сочетании с Backbone, чтобы избавиться от всего уродливого кода установки:

https://github.com/nick-jonas/assemblejs

Таким образом, вы можете ввести assemble init, чтобы сформировать базовый проект, и assemble build, чтобы запустить компиляторы и получить окончательную готовую к работе сборку.

person Nick Jonas    schedule 11.01.2013
comment
Как бы мне ни нравился requireJS, он сам по себе ОГРОМНЫЙ, поэтому я бы предпочел использовать вместо него Almond.js. Главное, однако, в том, что он по-прежнему основан на AMD, что многие хвалят (лично мне это тоже нравится, но моим коллегам нет). Итак, повторюсь: есть ли что-нибудь еще, кроме AMD? - person DLeonardi; 11.01.2013
comment
Посмотрите на это: UglifyJS: github.com/mishoo/UglifyJS Закрытие Google: developers.google.com/closure/compiler/docs/api-tutorial3 YUI: yuilibrary.com - person Nick Jonas; 11.01.2013
comment
UglifyJS, насколько я понял, это всего лишь минификатор, поэтому на самом деле он не создает сборку и, на самом деле, ничего не знает о зависимостях. Или я ошибаюсь? - person DLeonardi; 11.01.2013
comment
Я упомянул закрытие в своем ответе, поэтому я тоже об этом знаю. Тем не менее спасибо за наводку. - person DLeonardi; 11.01.2013
comment
Что касается YUI, я бы предпочел оставаться независимым от фреймворка. Если бы я рассматривал YUI, мне пришлось бы также рассмотреть систему сборки dojo, но я не собираюсь этого делать по причинам, которые в основном связаны с оптимизацией для сценариев с чрезвычайно низкой пропускной способностью. - person DLeonardi; 11.01.2013
comment
вы правы насчет Uglify, есть системы сборки, которые ИСПОЛЬЗУЮТ uglify, например r.js для проектов AMD: github.com/jrburke/r.js - person Nick Jonas; 11.01.2013

Возможно, вам будет интересно взглянуть на Grunt, инструмент командной строки с различными модулями для создания проектов javascript. Он использует npm для зависимостей и будет работать с модулями amd, но вы можете просто настроить его для объединения нужных вам файлов, используя ворчать-строить-конкат.

person slashnick    schedule 11.01.2013