Рационально ли использовать bem для небольших клиентских проектов по верстке

@voichev а на тему переопределения блоков и финальной сборки что-то можете сказать?

9 years ago

kompolom

@serhioone, я соглашусь с @voischev. Особенно когда проекты однотипные со своей библиотекой у тебя уже пол-проекта есть. Чтобы было меньше дублирования, в библиотеку стоит помещать общие стили и js. для этого их изначально стоит писать раздельно. Например, когда я писал проект, в common.blocks у меня была общая реализация, которую я мог скопировать в другой проект или добавить в библиотеку. а в desktop.blocks все было заточено под конкретный проект.

9 years ago

@kompolom этого я добиться и хочу, не совсем понимаю как технически это все должно быть реализованно, Например как вы дублировали из проекта в проект common.blocks? Просто копировали в директорию? Или через гит? Потом в папке desktop.blocks вы переопределяли стили и js? На сколько адекватный код получается после сборки?

9 years ago

@serhioone использовать оправдано для проекта любого размера.

По поводу дублирования стилей отвечу так:

cat b1.css
.b1 {
    width: 20px;
    color: red;
}

.b1 {
    width: 40px;
    color: green;
}

cleancss b1.css
.b1{width:40px;color:green}

9 years ago

возможно ли собрать проект например так:
js/
   script.js
css/
   style.css
html/
   index.html
   innerPage.html

Есть несколько способов, например:

Использовать file-copy для копирования собранных файлов в произвольные папки.
Написать скрипт, который бы сначала вызывал enb make, а потом раскладывал файлы в нужную структуру.

В обоих случаях потребуется написать правильный конфиг для borschik, чтобы сохранялись относительные пути. Подробнее об этом см. обсуждение в тредике https://ru.bem.info/forum/277/

9 years ago

Например как вы дублировали из проекта в проект common.blocks? Просто копировали в директорию? Или через гит?

git, а еще лучше — bower, чтобы явно управлять версиями подключаемых блоков.

В целом рекомендую в качестве примера смотреть на https://github.com/bem/project-stub/ — там подключаются bem-core и bem-components в bower.json.

9 years ago

kompolom

@serhioone, получается большая часть из git - блоки с прошлых проектов. Некоторые, которые "недостойны" библиотеки, руками копирую.

9 years ago

А как еще правильней организовать css файлы для адаптива например

header.css
header_mobile.css
header_tablet.css

Понимаю что вопрос тоже уже поднимался, но дельного ответа так и не нашел

9 years ago

@serhioone

header.css
header_mobile.css
header_tablet.css

так вполне нормально

9 years ago

@tadatuta извиняюсь за глупые вопросы, но ведь нужно еще где то прописать чтобы из блока собирались все css файлы.

9 years ago

можно использовать deps:

header.deps.js

({
    shouldDeps: { mods: { mobile: true, tablet: true } }
})

9 years ago

Недавно в рамках Html Academy устраивали митап по полному стеку. Я пришел к выводу, что:

вместо 6-10 сек. на написание разметки блока с emmet-ом, нужно потратить 2-3 минуты на поиск/создание нужного файла и написание в нем/них структур.
в стилевых файлах разумно выносить стили элементов в отдельные файлы (вместо использования амперанда), что сводит на нет часть того, что реально ускоряет работу при использовании препроцессоров.
конструкции, определающие разметку ОДНОГО блока вполне могут встречаться в РАЗНЫХ файлах

Вывод: для проектов проще «корпортативного портала» (новости, галерея, форум, переписка пользователей, каталог/магазин) БЭМ дает СИЛЬНЫЙ прирост времени разработки даже при наличии хорошоизменяемой кросспроектной библиотеки компонентов.

Ответ: нет

9 years ago

@nicothin

вместо 6-10 сек. на написание разметки блока с emmet-ом, нужно потратить 2-3 минуты на поиск/создание нужного файла и написание в нем/них структур.

Правда же, что никто не мешает добавить аналогичные шоткаты для любых структур и создавать их точно так же за 6-10 сек?

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

Так все-таки разумно или сводит на нет ускорение? ;) Для простых проектов вполне можно писать все в одном файле и никаких дополнительных расходов не будет. А если проект начнет разрастаться, постепенно раскладывать по разным файлам, чтобы его можно было нормально поддерживать.

конструкции, определающие разметку ОДНОГО блока вполне могут встречаться в РАЗНЫХ файлах

И снова: это возможность, а не необходимость. Если при разработке удобно разнести конструкции в разные файлы, например, чтобы получить разную разметку для десктопа и телефона или для авторизованного пользователя и анонима, то пожалуйста. А если это кажется лишним, то никто ведь не заставит.

9 years ago

voischev

@nicothin Ну незнаю, твое слово против моего. Кто прав? ;)

Если четно кажется все доводы кажутся надуманными. Но ок, не понимаю почему нельзя писать bemjson за 6-10сек, Ведь даже структуры проще чем у html. И прям в коде можно использовать JS для обработки данных.

Далее... Тут 6-10сек там 6-10сек, а если нужно что-то менять в нескольких местах? БЭМ прилагает из коробки возможность сделать компонент/шаблон блока, голый html ничего не предлагает. А если мы начинаем использовать шаблонизаторы, то чем это будет отличаться по скорости от БЭМ стека?

А если тебе нужно на 5 страницах блок поменять, что быстрее — изменить в файле кусок html и его копипастить 5 раз, или просто изменить один файл шаблона? ;)

Ну и вроде как давно понятно всем, что любой компонентный подход в любых инструментах будет сильно быстрее чем верстать html даже с Emmet. (Кстати не использую Emmet уже пару лет, а в css использую Hayaku ибо он не просто набор правил, а более человечен за счет не четкого поиска).

9 years ago

Правда же, что никто не мешает добавить аналогичные шоткаты для любых структур и создавать их точно так же за 6-10 сек?

Вот это может оказаться сложновато. Пример: необходимо обернуть несколько блоков в структуру из нескольких других блоков (к примеру, в .row>.col-xs-6>.chto-to-tut-escho). С Эмметом и обычным HTML это очень быстро — шоткат+ввод оборачивающей аббревиатуры. Как и каким образом можно это быстро сделать в bemjson? Есть инструменты? Я, правда, не знаю :) Еще пример: нужно обернуть 2-4 фрагмента разметки (разные,увы, а не повторяющийся блок) в 1-2 одинаковые обёртки. Еще пример: нужно убрать одну или две обёртки блока. Это я все к тому, что шоткаты бывают существенно хитрее простого ввода разметки.

Так все-таки разумно или сводит на нет ускорение? ;) Для простых проектов вполне можно писать все в одном файле и никаких дополнительных расходов не будет. А если проект начнет разрастаться, постепенно раскладывать по разным файлам, чтобы его можно было нормально поддерживать.

Это вероятность переделывать готовую работу.

Если это в одном файле изначально, то в ситуации, когда Элемент не нужен, придется руками его из стилевого файла блока удалить — долго, нужно помнить. (Я потому и написал, что разумно не стилизовать Элемент внутри стилевого файла Блока)

И снова: это возможность, а не необходимость. Если при разработке удобно разнести конструкции в разные файлы, например, чтобы получить разную разметку для десктопа и телефона или для авторизованного пользователя и анонима, то пожалуйста. А если это кажется лишним, то никто ведь не заставит.

Все верно говорите. Нюанс: это добавляет вероятность ошибки. Если (тем паче — в команде) есть вероятность неоднородности подхода, то обязательно возникнет неоднородность подхода. Следствие — увеличение времязатрат на редактирование.

@nicothin Ну незнаю, твое слово против моего. Кто прав? ;)

В моем случае — я, в Вашем — Вы :) Все как обычно :) Я привожу свои аргементы, Вы — свои. Мне интересно что получится в результате.

Но ок, не понимаю почему нельзя писать bemjson за 6-10сек, Ведь даже структуры проще чем у html. И прям в коде можно использовать JS для обработки данных.

Потому, что нет (или я о них просто не знаю) инструментов, ускоряющих написание, типа того же Эммета, с которым можно быстро создавать структуры любого размера (все необходимые атрибуты и форматирование возникнут без участия набирающего), быстро оборачивать имеющиеся структуры, убирать обертки, оборачивать каждую из нескольких структур во введенный фрагмент. JS для обработки данных для простого проекта? Ну, не знаю, не знаю...

Далее... Тут 6-10сек там 6-10сек, а если нужно что-то менять в нескольких местах? БЭМ прилагает из коробки возможность сделать компонент/шаблон блока, голый html ничего не предлагает. А если мы начинаем использовать шаблонизаторы, то чем это будет отличаться по скорости от БЭМ стека?

Скоростью набора разметки, конечно. Пока главный минус для меня лично — скорость работы с разметкой (больше набирать приходится, работа медленнее), а значит, нужен ОЧЕНЬ серьезный профит для выбора фуллстек-БЭМ.

А если тебе нужно на 5 страницах блок поменять, что быстрее — изменить в файле кусок html и его копипастить 5 раз, или просто изменить один файл шаблона? ;)

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

Ну и вроде как давно понятно всем, что любой компонентный подход в любых инструментах будет сильно быстрее чем верстать html даже с Emmet.

Именно. Вопрос только в скорости работы с компонентами и в комфорте (читай — скорости) работы со стилями. Если возможен инклуд фрагментов HTML в разметку, работа комфортнее за счет более быстрого редактирования и написания разметки. Ну и чисто личное: HTML ощутимо нагляднее, особенно в случаях наличия разметки, не являющейся блоками.

Полный стек БЭМ — не серебрянная пуля. Он очень хорош на КРУПНЫХ проектах (дает выигрыш для команды), но на мелких — очевидно избыточен. Есть и другие мелкие минусы, которые я заметил (должен сказать, опыт с полным стеком у меня более чем скромный, в отличие от опыта в верстке):

сильная завязка на jQuery
относительно муторный перенос подключения JS вниз страницы
НУЖНО БОЛЬШЕ СКОБОК
несколько разных синтаксисов (минимум один из них, по словам ведущего митапа, даже недокументирован)

п.с.: я очень люблю БЭМ как систему именования классов и уважаю фулстек, но использовать его на мелких проектах... нет. Пока, по крайней мере.

9 years ago

Вот это может оказаться сложновато. Пример: необходимо обернуть несколько блоков в структуру из нескольких других блоков (к примеру, в .row>.col-xs-6>.chto-to-tut-escho). С Эмметом и обычным HTML это очень быстро — шоткат+ввод оборачивающей аббревиатуры. Как и каким образом можно это быстро сделать в bemjson? Есть инструменты? Я, правда, не знаю :)

Мм... как там было? «Я реализую эту фичу за 5 строк» :)

function getBemjson(str) {
    return str.split('>').reverse().reduce(function(prev, cur) {
        return { block: cur.trim().substr(1), content: prev };
    }, {});
}

console.log(getBemjson('.row>.col-xs-6>.chto-to-tut-escho'));
// {
//     block: 'row',
//     content: {
//         block: 'col-xs-6',
//         content: {
//             block: 'chto-to-tut-escho',
//             content: {}
//         }
//     }
// }

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

Еще пример: нужно обернуть 2-4 фрагмента разметки (разные,увы, а не повторяющийся блок) в 1-2 одинаковые обёртки.

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

Еще пример: нужно убрать одну или две обёртки блока.

Вот уж где-где, а тут наличие декларативного шаблонизатора рулит и бибикает ;)

Это вероятность переделывать готовую работу.

Не очень понял, в каком случае появляется вероятность переделывать готовую работу и почему?

Если это в одном файле изначально, то в ситуации, когда Элемент не нужен, придется руками его из стилевого файла блока удалить — долго, нужно помнить. (Я потому и написал, что разумно не стилизовать Элемент внутри стилевого файла Блока).

Логично. Либо быстро писать все в одном файле, либо инвестировать в то, чтобы разбить все хорошо на файловой системе и дальше за всем следит автоматическая сборка. БЭМ предоставляет оба варианта, а разработчик выбирает, что ему удобнее. Причем варианты можно комбинировать.

Нюанс: это добавляет вероятность ошибки. Если (тем паче — в команде) есть вероятность неоднородности подхода, то обязательно возникнет неоднородность подхода. Следствие — увеличение времязатрат на редактирование.

Справедливо. Но. Без шаблонизатора вероятность ошибки увеличивается каждый раз, когда разработчик повторяет один и тот же кусок HTML с помощью emmet-шоткатов или еще как-то. А потом еще раз, когда он понимает, что во всех похожих кусках нужно внести одинаковое изменение и где-то забывает или вносит его чуть иначе, чем в остальных аналогичных конструкциях. Здесь снова побеждают декларативные шаблоны, позволяющие забыть про копипаст. Аналогия:

<div bgcolor="red"></div>
<div bgcolor="red"></div>
<div bgcolor="red"></div>

vs.

<div></div>
<div></div>
<div></div>

div {
    background: red;
}

JS для обработки данных для простого проекта? Ну, не знаю, не знаю...

Вот фрагмент, который требуется на самых простых проектах

<ul class="nav">
    <li class="nav__item">
        <a href="#Главная">Главная</a>
    </li>
    <li class="nav__item">
        <a href="#О компани">О компани</a>
    </li>
    <li class="nav__item">
        <a href="#Услуги">Услуги</a>
    </li>
    <li class="nav__item">
        <a href="#Вакансии">Вакансии</a>
    </li>
    <li class="nav__item">
        <a href="#Портфолио">Портфолио</a>
    </li>
    <li class="nav__item">
        <a href="#Контакты">Контакты</a>
    </li>
</ul>

Вот он же на JS:

{
    block: 'nav',
    content: ['Главная', 'О компани', 'Услуги', 'Вакансии', 'Портфолио', 'Контакты'].map(function(item) {
        return {
            elem: 'item',
            content: {
                block: 'link',
                url: '#' + item,
                content: item
            }
        };
    });
}

Даже уже здесь JS-вариант короче. А если потребуется что-то менять, то во втором случае это будет гораздо проще.

Скоростью набора разметки, конечно.

Мне кажется, что скорость набора занимает настолько незначительное время по сравнению со временем на обдумывание архитектуры или поиск хитрых багов, что его вообще можно не учитывать.

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

Чаще всего это один фрагмент, но с разным содержанием. Как в примере с меню:

<li class="nav__item">
    <a href="#НО-ВОТ-ТУТ—КАЖДЫЙ-РАЗ-РАЗНОЕ">И ТУТ</a>
</li>

сильная завязка на jQuery

На самом деле нет. И правда ли это серьезная проблема? Кстати, можно весь JS целиком писать полностью кастомный.

относительно муторный перенос подключения JS вниз страницы

o_0 Вообще он у нас из коробки подключается внизу.

несколько разных синтаксисов (минимум один из них, по словам ведущего митапа, даже недокументирован)

Всегда можно выбрать тот, который больше нравится (например, где меньше скобок ;)) Ну и, вроде, все документировано плюс-минус.

PS: Можно использовать полный стек и продолжать писать HTML руками с помощью emmet. См., например, https://github.com/tadatuta/bem-project-stub-he

9 years ago

Мм... как там было? «Я реализую эту фичу за 5 строк» :)

Едва ли :) В эммете и генераторы (tag>(tag>tag)*2)? и текстовые узлы, и фильтры, и уйма всего еще. Не верю, что Вы не видели http://docs.emmet.io/ :)

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

Скорость. С компонентным подходом бывают сложности — да, это не идеальный мир.

Не очень понял, в каком случае появляется вероятность переделывать готовую работу и почему?

Это про стили и разбивку стилизации элементов по файлам.

Причем варианты можно комбинировать.

Вот такими намерениями усеяна дорога в ад поддержки проекта :)

Справедливо. Но. Без шаблонизатора вероятность ошибки увеличивается каждый раз, когда разработчик повторяет один и тот же кусок HTML с помощью emmet-шоткатов или еще как-то.

Так он не повторяет. Он написал 1 раз и инклудит разметку туда, куда нужно.

Вот он же на JS

А как, скажем, третьему дать модификатор активности? (несколько менее красиво получится :) )

Мне кажется, что скорость набора занимает настолько незначительное время по сравнению со временем на обдумывание архитектуры или поиск хитрых багов, что его вообще можно не учитывать.

Увы, нельзя. По крайней мере, в моем случае. У коллег и студентов спрошу, но, думаю, отличия незначительные.

На самом деле нет. И правда ли это серьезная проблема?

Ну, 120+ Кб, вроде, не?

Вообще он у нас из коробки подключается внизу.

Хм... Что-то не так в демо-проекте было, значит. Я точно видел подключение в head и мы потратили определенное время на перенос его вниз.

Ссылку посмотрю, спасибо.

9 years ago

Едва ли :) В эммете и генераторы (tag>(tag>tag)*2)? и текстовые узлы, и фильтры, и уйма всего еще. Не верю, что Вы не видели http://docs.emmet.io/ :)

Я ведь заранее написал, что для полноценного конкурента emmet (возможно на его основе) несколько часов потратить придется, если по какой-то причине существующие решения не подходят. Кстати, по какой?

Это про стили и разбивку стилизации элементов по файлам.

Все еще не понимаю, почему возможность разбивки на файлы может заставить переделывать что-то готовое.

Вот такими намерениями усеяна дорога в ад поддержки проекта :)

И как мы только с yandex.ru справляемся? ;)

Так он не повторяет. Он написал 1 раз и инклудит разметку туда, куда нужно.

Я в предыдущем комментарии спрашивал про инклюд, когда внутри одинаковых фрагментов разный контент.

А как, скажем, третьему дать модификатор активности? (несколько менее красиво получится :) )

Ага. +1 строка:

{
    block: 'nav',
    content: ['Главная', 'О компани', 'Услуги', 'Вакансии', 'Портфолио', 'Контакты'].map(function(item, idx) {
        return {
            elem: 'item',
            elemMods: { active: idx === 2 }, // вот здесь
            content: {
                block: 'link',
                url: '#' + item,
                content: item
            }
        };
    });
}

Увы, нельзя. По крайней мере, в моем случае. У коллег и студентов спрошу, но, думаю, отличия незначительные.

Похоже, коллеги и студенты не овладели слепым набором, никогда не сталкиваются с багами браузерного рендеринга и заранее держат в голове готовую архитектуру любого проекта ;)

9 years ago

никогда не сталкиваются с багами браузерного рендеринга

да-да и не существуют :D

9 years ago

Kater-auf-Dach

Хмм… Позвольте влезть со своим комментарием в ваш калашный ряд и показать взгляд с позиции джуниора, так сказать) Как раз начал потихоньку копать БЭМ. По поводу скорости. Так как я начинающий, для меня скорость набора играет малую роль, в отличие от процесса мыслительного. Но первый раз взглянув на страницу, размеченную в bemjson, подумал: "Неужели вся эта простыня писалась руками?" Разметив первую страницу, понял, что все совсем не так страшно, а БЭМ-дерево выглядит гораздо нагляднее голого HTML. Создание отдельных файлов – тоже не так страшно, особенно через командную строку. А вот что действительно напрягает (возможно, пока) – необходимость прописывать теги через шаблонизатор. Уверен, что, как и писалось в самом начале обсуждения, наличие своей библиотеки в значительной мере решает все эти проблемы.

Далее, препроцессоры. По сути, мы теряем только вложенность, и то не всегда. Переменные, миксины, экстенды – все это можно смело использовать. Пользуясь случаем, задам вопрос: как можно подключить файлы с переменными и миксинами, чтобы не приходилось их импортировать в файл каждого блока, где они используются?

Скрипты сразу ставятся внизу страницы (юзаю project-stub).

К недостаткам full stack отнесу высокий порог вхождения. Особенно, если требуется тонкая настройка инструмента и правка конфигов - borschik, make.js…

Поэтому мой ответ на вопрос темы такой: full stack на маленьких проектах хорош, если ты уверенно владеешь этим инструментарием, у тебя есть библиотеки и заготовки проектов и/или велика вероятность, что тебе придется поддерживать его и дальше, и он будет расти. С другой стороны, как все это наработать, если не использовать, начиная с маленьких проектов?..

9 years ago

что действительно напрягает (возможно, пока) – необходимость прописывать теги через шаблонизатор

На самом деле можно «хардкодить» их прямо в BEMJSON:

{
    block: 'b1',
    tag: 'span'
}

Но это примерно как писать инлайновые стили в разметке — один раз нормально, но когда таких b1 появится несколько, дешевле окажется вынести в шаблон. Чтобы не напрягало, стоит добавить шоткаты в редактор. Например, чтобы по табу строка tag превращалась в block('').tag()('') и курсор автоматом прыгал в места подстановки.

как можно подключить файлы с переменными и миксинами, чтобы не приходилось их импортировать в файл каждого блока, где они используются?

С помощью DEPS.

К недостаткам full stack отнесу высокий порог вхождения

Есть такое. Сейчас активно занимаемся документацией, чтобы стало полегче. Кроме того, есть надежда, что постепенно сможем минимизировать количество кастомных инструментов (например, перейти на сборку с помощью gulp).

9 years ago

@nicothin Скрипт вырос до 80 строк и научился рисовать BEMJSON для конструкций типа b1>__e1*2>b3_theme_islands+_state_active, так что я решил запушить его на github и в npm :)

9 years ago

@tadatuta круто!

9 years ago

Есть такое. Сейчас активно занимаемся документацией, чтобы стало полегче. Кроме того, есть надежда, что постепенно сможем минимизировать количество кастомных инструментов (например, перейти на сборку с помощью gulp).

очень хотелось бы! особенно — Grunt- или Gulp-сборку и «дружественный верстальщику» демо-проект с минимумом лишнего.

9 years ago

Gulp бы сильно уменьшил порог входа я думаю, пока не понятно когда это чудо произойдет? Потому что пока мне видеться что итоговый проект перед cдачей заказчику все равно нужно через gulp прогонять

9 years ago

Kater-auf-Dach

На самом деле можно «хардкодить» их прямо в BEMJSON

Да, читал, но харкодить как раз и не хочется

Сейчас активно занимаемся документацией, чтобы стало полегче.

особенно — Grunt- или Gulp-сборку и «дружественный верстальщику» демо-проект с минимумом лишнего

Двумя руками за такую сборку. По поводу документации и демо - очень полезным оказалось видео Николая Ильченко с Loftblog (https://github.com/tavriaforever/project-stub)

9 years ago