Классический подход к управлению зависимостями в сравнении с RequireJS

[VasilioRuzanni]

Такая запись позволяет немного упростить форматирование и улучшить читаемость, но даже здесь приходится упоминать название зависимостей несколько раз. Кроме того, этот синтаксический сахар добавляет очередное усложнение в виде ещё одного способа обращения к зависимостям.

Вы неправы. Достаточно вот такой записи:

define(function (require) {
    var dep1 = require('dep1'),
        dep2 = require('dep2'),
        dep3 = require('dep3'),
        dep4 = require('dep4'),
        dep5 = require('dep5'),
        dep6 = require('dep6'),
        dep7 = require('dep7');
        // ...

});

[xpostman]

Возможно, но не в этом суть.

Этим примером я хотел продемонстрировать, что есть неудобство, для которого в RequireJS даже пришлось придумать воркэраунд. Helios Kernel не создаёт этого неудобства.

Ну и в итоге получается два способа делать одно и то же.

[Seldon]

Это не «воркэраунд», а непосредственный функционал библиотеки.

[wwwsevolod]

это плохо.
Уже есть 3 варианта, которые являются стандартами де-факто

1) AMD модули, которые использует, например, require.js
2) CommonJS модули, которые решают зависимости синхронно (например node.js, или для браузеров browserify).
3) И модули из стандрта ES6.

Для 1 и 2 есть куча плагинов, возможность загружать шаблоны, стили и так далее. И есть стандарт из будущего, который УЖЕ можно использовать, используя компиляторы соответствующие, или же на node.js, запущенным с определенным флагом.

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

[xpostman]

Если бы создатели этих вариантов следовали тогдашним «стандартам де-факто», не было бы сейчас ни нода, ни commonjs. Был бы бэкэнд на php и инклюд через script

[wwwsevolod]

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

[xpostman]

Так этот пост собственно и есть почти целиком про профиты. Вы правы в том, что мне было скорее интересно сделать эту штуку, но если бы не было профита — я бы наверное и не начинал.

Ну или можно объявить киллерфичей возможность запуска приложения в nodejs и в web без изменений и трансляции. У меня есть мысли развить проект как раз в эту сторону.

[B_Vladi]

Глядя на всё это, начинаешь ещё больше любить CommonJS модули.

[Regis]

Тогда уж посмотрите на библиотечку StealJS. Она предлагает такой формат:

steal(
"path/to/fooLibrary.js",
"path/to/barLibrary.js",

function() {
    // использование
    foo.doSomething();
});

По мне так это еще компактнее, чем Helios Kernel + нет этого магического вызова функции с именем «init».

[Regis]

«Собирающий» модуль будет выглядеть как

steal('deps/dep1.js','deps/dep2.js','deps/dep3.js');

Управление зависимостями библиотек, незнающих про зависимости выглядит так:

steal('jquery.js').then('jquery.ui.js');

Менять код самих библиотек не нужно.

[xpostman]

Спасибо, интересная библиотека, может быть по способу записи ближе всего к Helios Kernel. Только странно, что у steal столько разнообразного функционала: у меня впечатление, что некоторые вещи должны быть в виде отдельных серверных инструментов (steal.clean).

Про формат записи это же вопрос вкуса. Мне кажется, тут нужно стремиться не к компактности и минимальному размеру кода, а к ясности. Конкретно в steal такое место — аргументы функции steal, которые могут менять свой смысл (быть путём или колбэком) в зависимости от их количества. Ну то есть я бы не стал определять например тело модуля в виде анонимной функции прямо в перечислении аргумента только лишь потому, что язык позволяет этим способом сделать запись более компактной.

По такой же причине я однажды убрал поддержку нескольких аргументов в функции include() — в итоге каждый новый модуль перечисляется отдельным вызовом этой функции. Не потому, что мне было запарно пробегать по массиву аргументов, а потому что удобней читать, когда знаешь, что один вызов инклюда = одна зависимость.

А функция init() в некотором смысле даже аналогична сишному int main(). Её логичнее было именно определять в теле модуля, а не передавать в качестве аргумента как раз потому что это не колбэк.

[Regis]

аргументы функции steal, которые могут менять свой смысл (быть путём или колбэком) в зависимости от их количества

Там зависимости от количества нет. Только от типа. Все строки — пути к файлам. Все функции — коллбэки. Комбинации можно делать произвольные.

Ну а всё остальное — спор о вкусах :)

[rglab]

Как вариант: библиотека MicroRequireJs github.com/dsheiko/micro-requirejs.
Очень простое и легкое (1K) решение. Не требует адаптации зависимых модулей:

rjs.define("//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js", "jQuery");
rjs.require(['jQuery"], function(){
   var $ = window.jQuery;
});

[sigod]

['jQuery"]

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

[kurumpa]

include("path/to/myLibrary.js");

init = function() {
    // здесь библиотека подключена и можно её использовать
    myLibrary.writeHello();
}

а как насчет use strict?

[xpostman]

Интересно, я об этом ещё не задумывался, надо поразбираться.

Проблема в том, что если снаружи всех функций написать var init = ..., то, насколько я помню, для nodejs будет объявлена всё равно локальная переменная модуля, и возможно это сломает совместимость…