jade вместо json — немного странно звучит. Тут вариантов 2: Либо вопрос про bemjson и тогда ответ да: например, можно взять yaml, но придется написать (или найти готовую?) технологию для его разбора. Либо вопрос про шаблоны на jade и тогда дело обстоит несколько сложнее, но удасться использовать его только частично, плюс надо будет продумывать хелперы для описания внутренних блоков (аналоги ctx.content(...), и других).

Про livereload обсуждалось в https://ru.bem.info/forum/289/

@lehakos В целом ответ на оба вопроса — да. Причем самыми разными способами. Чтобы мочь посоветовать что-то конкретное, нужно понимать задачу. Расскажи подробнее, чего хочется достичь в результате, я напишу, как это можно сделать.

@lehakos Как раз вчера задался этим вопросом :) Решил сделать сборщик для вёрстки с использованием jade. Немного эмулирующий сборщик из bem-tools. Сейчас он на этапе проектирования-разработки

В кратце по структуре: src/layouts - наши лайоуты src/pages - наши страницы, которые оборачиваются в лайоуты src/blocks - блоки(миксины) src/blocks/block/*.{jade, styl, js} - ресурсы блока dist - место хранения собранных страниц

Процесс сборки: Запускаешь gulp пишешь вёрстку в jade. Из исходников собирается html. По этому html строится список блоков (идёт поиск на основе аттрибута class). Затем собираются стили для страницы.

Из плюсов:

• более "привычный" способ разработки;
• быстрее собирает проект (из-за отсутствия библиотек);
• gulp - более привычный в веб-разработке.

Из минусов:

• не даёт такой мощи, как bem-tools;
• пока В РАЗРАБОТКЕ.

@tadatuta Вот только задумался... А не лишний ли это велосипед будет?

П.Н. На данный момент есть сборщик, который работает в полуавтоматическом режиме. Он работает по принципу построения зависимостей в ручном режиме. Т.е. есть файл - в нём есть список блоков, которые нужно собирать. По нему gulp и собирает наши страницы (стили и js для них). Поддерживается переопределение для разных страниц.

@belozyorcev Основная проблема там зависимости, ты уже придумал как будешь рулить их? И будешь ли?

Так-то можно было технологию для ENB сделать ;-)

@zxqfox какие именно ты имеешь ввиду зависимости? До этого я делал по способу описания подключаемых блоков в файле. Всё отрабатывало хорошо. В команде данный подход быстрее прижился, чем использование ENB.

Если ты про стили, то сборка из html осуществляется в 2 прохода.

• строится массив всех блоков на странице;
• убираются повторы, остаются только последние вхождения.

Этот сборщик - просто упрощённая форма разработки по БЭМ без bem-tools.

Так-то можно было технологию для ENB сделать ;-)

Именно поэтому меня гложет чувство, будто отхожу от течения...

какие именно ты имеешь ввиду зависимости? До этого я делал по способу описания подключаемых блоков в файле.

Я про *.deps.js, расскажешь про свой файл?

@zxqfox ну вот так он выглядит в бою

{
    "libs": [
    ],


    "pages": {

        "global": [
            "i-bem",
            "i-engine-starter",
            "reset-styles",
            "page",
            "link",
            "sidebar",
            "user",
            "avatar",
            "nav",
            "nav-history",
            "header",
            "logo",
            "content",
            "tabs",
            "tables",
            "bar-chart",
            "bars",
            "button",
            "students-form",
            "picker",
            "picker-date",
            "picker-time",
            "form",
            "card-group",
            "schedule",
            "time",
            "day-week",
            "pie-chart",
            "pie",
            "point-field",
            "point-form",
            "star-rating",
            "group-rating",
            "number-rating",
            "more-info",
            "board-rating",
            "stat-card",
            "history",
            "ajaxlink",
            "schedule-form",
            "login-content",
            "login-form",
            "media-print",
            "d3",
            "xcharts",
            "jslib-tempus",
            "graph",
            "docstable",
            "archive"
        ],

        "teachers__view": [
            "page",
            "graph"
        ]
    }
}

можно указывать подключаемые библиотеки в виде переменных для описания блоков globals - общий js|css для всех страниц teachers__view - переопределение, раширение js|css для конкретной страницы.

upd Хотя намного лучше было бы в yaml такой подход делать

@belozyorcev да суть одно.

А по блокам не раскидываете зависимости?

Нет. Не было необходимости. Хотя думал над этим.

@belozyorcev У нас хватает историй, когда ребята начинали с написания своей системы сборки, а спустя какое-то время обнаруживали, что переизобретают bem-tools / ENB и переходили на них.

Но в целом, если текущий сборщик решает все ваши задачи, то не вижу причин его не использовать. Мы и сами уже давным-давно думаем о том, чтобы полноценно поддержать gulp в качестве сборщика. Но у нас тоже «пока в разработке» ;)

@tadutata значит скоро будет ещё одна история ;)

Уже есть такой сборщик — verstat (http://verstat.info) jade + bem + stylus + less + coffeescript + livereload + ...

Можно собирать js и css с помощью enb make, а всё остальное, что сложно и\или непонятно, как сделать с помощью enb, делать с помощью gulp (webpack, grunt и т.п.).

Единственно придётся написать обёртку вокруг enb make, которая поймёт, что эта команда отработала. В целом, это несложно делается с помощью стандартного child_process.

Я планирую в ближ. время сделать что-то подобное тут — https://github.com/DimitryDushkin/bem-light-example Минимум конфига enb make для самых основных вещей (типа уровней переопределения, компиляции sass, autoprefixer), а всё остальное (svg-спрайты, livereload, деплой и пр.), уже gulp или подобным.

@tavriaforever

Мы пробовали использовать jade. Это очень порочный путь! Пришлось потом выпиливать.

Лучше сразу bemhtml или BH. Т.к. у jade все очень плохо с переопределением и доопределением и компиляция сложная получается.