Вроде как был где-то разговор, в котором пришли в выводу что с ymodules так же как и с browser.js круто будет работаеть переопреледения/переопределения на уровнях.... Но я могу ошибаться

@voischev конечно круто, и логично, но тогда express тоже надо оформить node.js модулем, и можно иметь какую-то универсальную штуку, которая будет стартовать это все хозяйство. так ведь? ;)

@zxqfox так ведь! У тебя то какие мысли? )

Я свои мысли оформил так: https://github.com/zxqfox/pym ;-) Но потом подумал, что может зря это я так...

Я использую технологию сборки node.js.) Она никак не завязана на ymodules, равно как и browser.js. Пользоваться ymodules там, где есть CommonJS - не странно, CommonJS не позволит тебе как минимум проверить зависимости до старта проекта. Ну и доопределения сюда же. Что значит "пытаться" и зачем придумывать велосипед? Почему в отдельный бандл? Процесс сборки стандартный, bundleName.node.js соберется в каждом бандле. Что именно хочется упростить?

@apsavin Тогда получится не одно приложение, а N (по кол-ву бандлов).

Хочется писать весь бекенд в блоках и запускать, скажем:

var modules = require('bundleName/bundleName.node.js');
modules.require(['app'], function (app) {
  app.run();
});

Мужчины, для развития мысли, пример такого подхода https://github.com/bem/bem-site-engine/blob/dev/src/blocks/server.blocks/middleware/middleware.node.js

@tavriaforever Точно, спасибо! ;-)

Может еще какие-то мысли есть?

@zxqfox bem-yana по сути и является express-ом, распиленным на блоки и завернутым в ymodules. правда проект давно не развивается и изрядно устарел.

если попробовать срезюмировать полученный опыт, то он такой: очевидно, что БЭМ можно использовать и для серверного кода — у нас несколько больших интранет-проектов работают на основе bem-yana.

чтобы принять решение, важно определиться, действительно ли:

1. есть общий код между клиентом и сервером
2. нужна возможность подключать модули асинхронно (например, когда модуль БД провайдит себя после того, как установил соединение с базой)
3. нужно переопределять модули по уровням (например, у нас внутри есть полный аналог bem.info, но с яндексовой спецификой. оба сайта работают на bem-site-engine и мы там это активно используем).

если хотя бы какое-то из данных утверждений верно для проекта, то можно посмотреть в эту сторону. а если эти возможности не нужны, то стандартные средства node.js скорее всего окажутся более удобными.

@tadatuta Ты мне сейчас напоминаешь сомневающихся в БЭМ методологии, которых я видел года 2-3 назад на различных мероприятиях ;-) Они говорили: зачем нам это все, если мы можем сразу на html садиться и верстать. Какие сборщики, о чем вы говорите, но в целом я согласен, только пунктов больше.

Я бы еще добавил:

1. Хочется быть уверенным до запуска, что все зависимости отрезолвлены (практически, из коробки);
2. Не хочется, чтобы что-то падало, если чего-то не отрезолвилось (опять же из коробки);
3. Из ym, 4 и 5 еще следует, что появляется возможность реализовывать плагины со своими зависимостями, которые реализуют какое-то апи, которое можно заменять аналогами с тем же апи; и т.д.

Но я уверен, что и для мелких проектов полный ym более удобно, чем смесь commonjs с ym.

Единственная проблема — это как собирать модули для бекенда из библиотек и перезагружать само приложение в нужное время, но она решаема.

@zxqfox Ты так говоришь, как будто мои проекты написаны без ym ;)

Я говорю лишь о том, что когда есть npm, где over 100k пакетов и за основу выбран какой-то не БЭМ-based фреймворк, а ты вдруг начинаешь все это переписывать на блоки без реальной на то потребности (а потом регулярно портировать апдейты из исходных проектов), то это не самая крутая идея. bem-yana-то в конце концов загнулась.

А если ты действительно понимаешь в чем профит и этот профит будет активно использоваться, то сомневаться не о чем ;)

PS: расскажи подробнее про проблему со сборкой и перезгрузкой приложения, возможно, смогу что-нибудь посоветовать.

bem-yana несколько не то, что я себе представляю, но начало хорошее. Портировать ничего не надо, потому что синхронно подключить пакет из асинхронного modules.define/.require возможно. Опять же, существуют peerDependencies. ;-)

О проблеме перезапуска: Запрос приходит из браузера на сервер, мы его чем-то ловим, роутим куда-то, инициируем пересборку, собираем файлики, .bemhtml/.bh, .css, browser.js, .node.js и тут оказывается, что .node.js то другие, и стоило бы их пересобрать до передачи туда запроса ;-)

Не нужно хотеть пересобирать node.js по запросу из браузера, вместо этого отлично подойдет файл-вотчер (например, nodemon).

есть общий код между клиентом и сервером

Если общий код научить провайдится в нужны модульные системы, то совсем не обязательно использовать ym на ноде.

Например, писать код в es6 modules. При сборке browser.js обарачивать в ym, а при сборке node.js прокидывать в module.exports.

нужна возможность подключать модули асинхронно (например, когда модуль БД провайдит себя после того, как установил соединение с базой)

Чем плохи подобные решения? https://github.com/MangroveTech/koa-mongo

нужно переопределять модули по уровням (например, у нас внутри есть полный аналог bem.info, но с яндексовой спецификой. оба сайта работают на bem-site-engine и мы там это активно используем).

Интересно насколько это нужно в реальной жизни, всем кроме bem.info.

Портировать ничего не надо, потому что синхронно подключить пакет из асинхронного modules.define/.require возможно. Опять же, существуют peerDependencies. ;-)

@zxqfox, можешь раскрыть мысль?

@andrewblond загрузчик, который умеет искать в пакетах?

Интересно насколько это нужно в реальной жизни, всем кроме bem.info.

Банально, есть CMS в виде библиотеки блоков, есть блок страниц сайта, в нем модель страницы, которую мы перегружаем доп полями в плагине (библиотеке) или нашем приложении. Пойдет?

Например, писать код в es6 modules. При сборке browser.js обарачивать в ym, а при сборке node.js прокидывать в module.exports.

Думаю, что для начала можно и без es6. Это уже детали реализации.

@andrewblond А как ты хочешь асинхронно провайдить?

export yield {}?