bemtree - это просто шаблоны, нет ничего плохого в шаблонах на клиенте.

Более того — для Single Page Application (или близкой к SPA архитектуре) в них есть еще и куча плюсов ;-)

Так их можно подключить на клиент в общий js? Если так, то теряется смысл моды def() и content() для bemhtml, т.к преобразование по этим модам необходимо выполнять в bemtree.

@4ok безусловно их можно подключать в общий js. def() в BEMTHML действительно чаще всего не требуется, а content() нужен для кейсов создания число оформительских оберток и добавления всяких визуальных штук в разметку, которые не несут особой семантической нагрузки.

Приведи пример пож-то визуальных штук, чтобы было ясно, что именно имеется ввиду, спасибо.

@4ok например, элемент для иконки, какие-то разделители и прочие украшательства, которые по каким-то причинам не удается выразить через :before и :after в CSS

@tadatuta, спасибо, понял.

В bemtree шаблонах на сервере я часто использую require необходимых модулей, выходит, что в случае подключения этих шаблонов на клиент, необходимо придумать как обходится без них. Что можно придумать в этом случае?

Например необходим модуль форматирования даты - для ноды это require в самом bemtree, а на клиенте подключение через <script src="..."></script>. Но в этом случае сам require в шаблоне я так понимаю нужно удалить и передать этот модуль как параметр в bemtree.

Правильное направление мысли?

@4ok можно заворачивать все в YModules, которая работает и на клиенте и на сервере.

Получится что-то типа:

// m1.node.js
modules.define('m1', function(provide) {
    provide(require('path/to/something');
});

// m1.browser.js
modules.define('m1', function(provide) {
    provide(/*borschik:include:path/to/something*/);
});

@tadatuta - супер! Но как потом эти объявленные модули использовать в bemtree? Не соображу никак.

@4ok например, вот так:

modules.require(['m1', 'BEMTREE'], function(M1, BEMTREE) {
    BEMTREE.apply({ block: 'page', modules: { m1: M1 } });
});

дальше можно пробросить все необходимые модули вглубь по дереву в шаблонах:

block('page').def()(function() {
    return applyNext({ modules: this.ctx.modules });
});

и, соответственно, они будут доступны из всех блоков:

block('my-block').content()(function() {
    return this.modules.m1('trololo');
});

Я вот подобное в BH изобразил для инлайновых svg.

if (require) {
  require('./kg-glyph.prepare.js'); // prepare json from folder with svg
  var glyphs = require('./glyphs.json'); 
} else {
  var glyphs = {/*borschik:include:../../common.blocks/kg-glyph/glyphs.json*/};
}
module.exports = function (bh) {
  bh.match('kg-glyph', function(ctx, json) {
    return glyphs[json.glyph+'.svg'];
  });
};

@tadatuta а на сколько адекватно использовать пободную конструкцию?

@Guria Нормально )

Я бы еще предложил посмотреть в сторону инлайнинга SVG прямо средствами borschik:

{
    "freeze_paths" : {
        "libs/**": ":base64:",
        "libs/**/*.svg": ":encodeURIComponent:",
        "*.blocks/**": ":base64:",
        "*.blocks/**/*.svg": ":encodeURIComponent:"
    }
}

• https://ru.bem.info/articles/borschik/#Динамический-url

Хотелось бы тогда технологии делить на серверные, клиентские и общие по суффиксу. Правильно ли разделить их след. образом - *.node.bemtree, *.browser.bemtree, *.bemtree?

В силу того, что мы можем доопределять функциональность на разных уровнях и нас никто не может оставить от этого — не проще вынести общий функционал на уровень common.blocks, серверный на server.blocks, и браузерный в browser.blocks?

Но если очень хочется — можно и так разделять, только надо будет технологии написать, по аналогии с enb-modules (или аналогов для bem-tools).

@4ok да, вполне можно делить так (для консистентности можно еще последовать принятой в bem-core схеме и общее для всех платформ явно назвать vanilla.bemtree), а можно и разнести по уровням, как предлагает @zxqfox. Но я бы рекомендовал не плодить сущностей и ограничиться просто использованием depsByTech, если только не предполагается, что будет много блоков, которые принципиально несовместимы, но называются одинаково.

@tadatuta, @zxqfox - доступно, спасибо.