Ну да.

Со стороны заходя во внешнюю библиотеку блоков свёрстанных по БЭМ, ожидаешь увидеть сниплеты на обычном html,css,js. Так, как рассказывали раньше в докладах об файловой организации библиотеки готовых блоков в Яндексе.

Ну с таким же успехом можно забирать копи-пастом из примеров на страницах внутри самой http://bem.github.com/bem-bl/index.ru.html

А блоки, что были у вас раньше, как рассказывали раньше в докладах об файловой организации библиотеки готовых блоков в Яндексе: сниплеты в папках где отдельно css, html, js и т.д - они есть? Может в таком бы виде где-то выложили, было-бы клёва.

Может быть bem-bl просто непредназначена для тех кто практикует БЭМ вне Яндекса и без bem-tools и остальных ненужных в обычных компаниях окружения?

Как я понимаю, вам не хватает собранных html для блоков.

Вариант в лоб — создать в pages отрисовку нужных блоков с нужными модификаторами и после сборки всего проекта использовать как ssi или еще как-то.

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

Но оба эти варианта не имеют смысла, по-моему мнению, т.к. теряется декларативность и гибкость. Вам в итоге все равно руками придется собирать страницы, но зачем? Может поделитесь?

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

Если речь именно о верстке для разрабов — я бы вам посоветовал сверстать ваш проект, над которым вы много работаете, под бэм-тулс. Благо, переопределить правила именования технически реально — значит вам подойдет.

В итоге у вас будет своя библиотечка со своими страницами (pages), которые вы в итоге будете отдавать разрабам в виде css, js (как в собранном виде, так и отдельно, по желанию), и html, и если что-то нужно будет поправить — останется только пересобрать или запустить bem server.

Мне (как и многим думаю) была бы полезна публичная библиотека типовых сниплетов блоков.

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

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

Нет, не прийдётся, все проекты полностью, абсолютно, независимы друг от друга и никак не связаны. Более того, сниплеты, которые копируются из библиотеки блоков всё равно нужно менять, дорабатывать под конкретную ситуацию. И разумеется ни какими ни уровнями переопределений, а внесением правок в скопированный сниплет.

Вам в итоге все равно руками придется собирать страницы, но зачем? Может поделитесь?

Потому что мы не собираем вёрстку из готовой библиотеки блоков, у нас как обычно: css/main.css, js/main.js, CMF, шаблоны. Библиотека блоков есть, но из неё просто копируется что нужно на проект. Никаких связей не создаётся, всё полностью независимо, отдельные репозитории. Нет и не может быть задач вида "обновить какой-то блок на всех страницах разных проектов".

Это классический аутсорс, как и у многих веб-студий: куча небольших сайтов, вообще никак не связанных, на разных движках и т.д. На разных, потому что ещё приходят-же уже существующие сайты на поддержку, которые делал кто-то другой, а в новых клиент может потребовать выбрать CMF, которую он хочет (у него могут быть остальные сайты например на symfony).

 1. Рисуются wireframes, утверждается структура

 2. Рисуются макеты в PSD

 3. Верстается статический сайт

 4. Программится backend под него на CMF (как правило на Kohana)

 5. Интегрируется вёрстка, выкатывается в продакшен.

Не выйдёт. Это будет лишь никому не нужный промежуточный этап.

После сдачи сайта его будут дорабатывать уже на основе продакшен-кода: там обычный css, js, шаблоны CMF. Их будут править другие разработчики. Возможно даже менеджеры со стороны клиента. Возможно даже не на тестовом сервере, а сразу на продакшене. И страшно подумать - может даже и мимо системы контроля версий, прямо на FTP. Ну потом синхронизируются конечно.

Зачем тут весь головняк с bem-tools, когда нужно просто открыть css, изменить одну строчку и залить на FTP?

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

Cпасибо.

Меня смутило что это публичная библиотека типовых блоков. Я (несмотря на все пересмотренные доклады и статьи) расчитывал найти в ней не только bemjson, но и также исходный (или скомпилированный стандартный) plain html и css.

Что-то вроде библиотеки виджетов. Независимых блоков-кирпичиков которые могут (и будут) использовать разные сторонние разработчики на своих проектах. Pull request'ить свои доработки. Почему и удивлялся и спрашивал про отсутствие максимального сброса стилей у типовых элементов.

А тут не бывает ситуаций что блок копируется и правится руками (лишнее выкинул, нужное - дописал), вставляется куда-то (где может быть и БЭМ никогда не было). Он подключается и переопределяется, но не копируется .

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

А так хочется библиотеки сниплетов по БЭМ. Я считаю это именно то, что нужно обычному рынку.

1) Расскажите, почему не используете bem-tools в разработке, с какими трудностями столкнулись при внедрении?

2) Снипппет как хочется увидеть? В Виде папки 

name-of-block => [ name-of-block.html, name-of-block.css, name-of-block.js ]?

3) js как хочется писать, в jQuery/другая либа общего назначения или BEM?

К сожалению, бем немножко про другое. Это не набор плагинов для jquery. Даже когда вы начинаете просто использовать i-bem — вам уже желательна сборка js, css в бандлы — под каждую страницу свой. А когда речь заходит о всем сайте — получается нужны свои тулзы для сборки. Блоки в любом случае надо собирать, это не сниппеты.

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

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

отдельные репозитории

Не аргумент

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

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

Т.е. сначала мы делаем от корня, потом от веток? И ветки диктуют дереву свои правила? Боюсь, с таким подходом я бессилен чем-либо вам помочь.

Лично я выбирая между один раз головняк с бэм-тулс и каждый раз головняк при правке кучи текстовых файлов — выберу первое, потому что хоть это и дольше по началу, нужно разбираться, но в будущем профит по времени мне гарантирован, а время, знаете, оно бесценно

То, что bem-bl не подошла именно вам, совершенно не означает, что ей никто не пользуется вне Яндекса

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

Не надо утрировать. Речь о тех проектах, которые вы сами делаете и поддерживаете. Если студия получает клиента с сайтом, собранным в 90-х (или по типу) на коленке — для меня тут два варианта: либо оставить как есть, и поправить то, что ему критично, либо, если работы много или на длительный,срок на постоянное обслуживание — немножко распилить на блоки, выделить блок страницы и разные блоки для центральной части (1-n на каждой странице). Делается второй вариант часа 2-4, поэтому, если там работы на день, то смысла, думаю нет, а если сайт нужно дорабатывать много — то несомненно есть, вне зависимости от того, на чем он написан (joomla, rails, ...).

К сожалению, бем немножко про другое. Это не набор плагинов для jquery.

Я знаю про что БЭМ, спасибо Следил за публикациями Харисова, общался на конференциях ещё в 2008, когда и слова такого БЭМ - не было, приезжал в Симферополь, где он наконец меня укусил и я прошёл инициацию.

Блоки в любом случае надо собирать, это не сниппеты.

Почему надо? 

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

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

БЭМ != bem-tools и прочее. «БЭМ — это в первую очередь паттерн. Паттерн мышления и разработки.» @harisov

Методология. БЭМ прошёл большой путь от просто независимых блоков (не АНБ, а ещё просто независимых), до того что есть сейчас. И все, все варианты: https://www.slideshare.net/yandex/minsk-harisov (начиная со стр. 82) - это всё БЭМ.

Я не утрирую. Я говорю о реальном мире, а не комфортной разработке внутренних проектов.

Что означит для вас "распилить на блоки, выделить блок страницы и разные блоки для центральной части (1-n на каждой странице)"? Сверстать в АНБ? Так и так есть. Или о чём вы?

Грубо говоря, если у вас 10 страниц, у которых всё вне некоего