БЭМ расшифровывается как «Блок Элемент Модификатор». Это подход к web-разработке, позволяющий быстро создавать сайты с гибкой архитектурой. Он знаком многим, кто занимается HTML/CSS вёрсткой.

Изобретённый в Яндексе, БЭМ постепенно проникает и в разработку других компаний.
В данный момент основные мейнтейнеры работают над выводом в Open Source фреймворка, построенного по методологии БЭМ, инструментов и многих полезных утилит.

Вашему вниманию очередной выпуск подкаста о веб-разработке «Сделайте мне красиво!»

Show notes:

• Асинхронная загрузка модулей через js (на github + разъясняющая статья)
• Библиотека готовых решений от Твиттера
• Разговор про прогресс БЭМа, подробная статья для начинающих
• underscore — набор простых методов для манипуляций с объектами (русская документация)
• Объединенная документация по HTML, CSS, jQuery, DOM

Наши ссылки: RSS и лента на rpod.ru

Про БЭМ (методология написания CSS от Яндекс — Блок__Элемент_Модификатор ← наиболее правильная запись расшифровки) нынче можно услышать на каждом шагу. Дело оказалось благим и покатилось по миру. Яндекс даже полез в W3C (связано это или нет — не знаю, но надеюсь, что да — [на самом деле нет]).

Думаю многие, кто ещё не пробовал, но прочитал описание БЭМ, задаются справедливым вопросом: «какая практическая польза от всего этого действа?» На самом деле, не смотря на то самое развёрнутое описание, конкретно уловить основную «фишку» довольно сложно. Описано конечно много плюсов и общее ощущение от методологии положительное, и кажется, что вроде как и не плохо бы попробовать, но нехватает чего-то конкретного. Прямо вот примера на живом что ли. Вот у меня сайт, вот вёрстка не по БЭМ, почему я должен всё менять? Особенно, если учесть тот факт, что БЭМ в принципе отметает все селекторы кроме классов, неужто за это время столько умных мужей в W3C не осознали, что всё настолько неправильно?

За сим возьму на себя смелость привести несколько примеров с которыми вы (конечно если вы каким-то образом связаны с вёрсткой) сталкиваетесь, не побоюсь этого слова, ежедневно. И что изменится в таких ситуациях если бы вёрстка была изначально выполнена в БЭМ.

По мотивам статьи на Хабре и флейма вокруг нее. Статья написана для тех кто хочет попробовать БЭМ, но не знает с какой стороны за него взяться. При первом взгляде на БЭМ, он кажется логичным и невероятно удобным. Но при попытке реализовать пользователь сталкивается с препятствиями, которые нивелируют все достоинства. Я не знаю как и почему создавалась эта методология, меня это не парит, если использовать правильно, то это прикольно, я же не задумываюсь для чего когда-то строили автомобиль или самолет, зато сейчас им пользоваться удобно, это же просто удобный инструмент. Знаю только, что при создании, никто не собирался стили и классы писать одним полотном.

Я попытаюсь рассмотреть один из многих вариантов применения методологии БЭМ на практике, который не только соответствует духу, но и рекомендациям создателей.

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

В данной статье я хочу рассказать, о том, как можно сверстать «хорошо» (по крайней мере структурировано ;), а заодно рассказать и о методологии, которая может «упростить жизнь» при верстке. Структура поста будет следующей:

• BEM
• Собственно пример — как сверстать страницу

Вроде закончилась неделя 30 строк кода и взамен ей видимо пришла неделя "БЭМ". Причем прослеживается достаточно забавная очередность топиков:

• Верстаем веб-страничку за 15 мин.
• На БЭМ'е было бы лучше!
• Сами вы ешьте свой бем, у меня препроцессоры!

И самое интересное, как всегда, в комментариях — чистой воды холивар. Но из-за чего? Почему одни свято верят в методологию БЭМ'а, другие презирают её как узурпатора семантичности? Я попробую изложить свою точку зрения на суть всего холивара и прояснить в первую очередь для себя положение БЭМ'а в собственном мироздании.

Введение

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

В разработке интерфейсов отдельные фреймворки уже не так важны: когда инструменты доступны, наша задача сводится к выбору нужных. Чтобы сделать правильный выбор, следует начать с общего подхода, с методологии. Большинство методологий, однако, разработаны крупными компаниями. Применимы ли они в маленьких проектах или для успешного использования их нужно переизобретать заново?

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

Я проработал в Яндексе достаточно долго и видел, как эта методология работает на больших проектах. В Яндексе БЭМ используют для разработки CSS- и JavaScript-компонент, с помощью этой методологии также пишут шаблоны и задают зависимости между компонентами. Есть БЭМ-инструменты, поощряются различные эксперименты с кодом, исследования. В масштабах большой компании эти трудозатраты окупаются и дают Яндексу возможность быстро и качественно разрабатывать сотни сервисов одновременно.

Могут ли маленькие команды получить от БЭМ то же самое? Я совершенно не был в этом уверен. Всё же БЭМ — абстракция, которая поставляется вместе с инструментами и технологиями. Для маленькой компании польза от переключения на «полный стек» этих технологий — сомнительна, многие из инструментов изначально приспособлены под крупные и сложные задачи. Быть может, тогда полезной окажется сама идея, сама методология?

Изначально эта моя статья была опубликована в известном многим журнале Smashing Magazine. Но я решил, что и на Хабре она может быть интересна, ведь многие здесь занимаются собственными небольшими проектами.

Всем привет! У нас отличная новость!

Буквально на днях к нам приходили наши друзья из «Яндекса» и рассказывали о том, как и зачем они в разработке используют OpenSource проекты. О том как они развивают БЭМ методологию, как ее используют в сервисах «Яндекса» и какие инструменты пишут для всего сообщества. Было очень круто и огромное им за это спасибо, а все подробности, материалы и что мы из этого вынесли под катом.

Когда появился node.js, многие web-разработчики стали задумываться о возможности использовать один и тот же код как на клиенте, так и на сервере. Сейчас существует несколько фреймворков, ставящих подход «пишем код один раз, используем везде» во главу угла, время от времени появляются новые. Вот и я не смог пройти мимо, пишу подобный микро-фреймворк — bnsf. Он предназначен для тех, кто предпочитает создавать front-end своих приложений по БЭМ-методологии, пользуясь соответствующим набором технологий и инструментов.

Давайте попробуем начать писать front-end для простого одностраничного web-приложения, используя bnsf. Чтобы не отвлекаться на создание back-end части, будем использовать в качестве back-end'a API vk.com. Наше приложение будет состоять всего из двух страниц, главной — с формой поиска пользователей по идентификатору — и вторичной, на ней будем выводить информацию о выбранном пользователе.

На прошлой неделе BBC рассказала, что для новой версии главной страницы использовала методологию БЭМ, созданную в Яндексе. По такому случаю мы решили поднять материалы мастер-класса «Разрабатываем сайт с нуля на полном стеке БЭМ-технологий» и рассказать вам, как начать использовать полный стек БЭМ-технологий в своих проектах.

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



В статье мы расскажем, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомимся с готовыми библиотеками блоков и инструментами для автоматизации сборки. Покажем, как разные инструменты — например, autoprefixer, css-препроцессор Stylus или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки по БЭМ.

На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельно остановимся на декларативных шаблонах BEMHTML и BEMTREE, которые позволяют преобразовывать данные в БЭМ-дерево, описанное в формате BEMJSON и, затем в HTML. Рассмотрим в деталях, как написать серверную часть приложения по БЭМ-методологии.

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



Если вы также используете deps.js файлы формата enb, то bemy будет вам особенно полезен, так как приняв на выход путь к этому файлу, bemy создаем файловую структуру блока (по умолчанию с css-файлами).

Разработчик Бен Фрейн (Ben Frain) однажды заметил: «Писать CSS-код легко. Масшабировать и поддерживать его — нет».

К счастью, на просторах интернета можно найти множество решений этой проблемы. В данной статье рассмотрены основные киты структуры CSS-кода, а также интересные рыбы/млекопитающие поменьше.

Статья служит лишь памяткой или кратким справочником — для подробного ознакомления с методологиями настоятельно рекомендуется изучать оригинальную документацию.

Итак, начнем.

«Пиратское» видео доклада «Пишем #b_ правильно» с конференции «WebCamp 2015: Front-end Developers Day», прошедшей 4 июля в Одессе.

Как сверстать сайт вручную «по-БЭМ» без классов «block__element__element», и на реальном примере со всеми его проблемами, а не меню-пункт_меню-ссылочка, как вы видели раньше. Без BEMJSON, BEM Tools, но с миксованием, модификаторами и разбором ошибок.

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

Слайды: delka.github.io/talks/webcamp/2015/bem

БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

Эти события натолкнули нас на мысль ещё раз вспомнить и рассказать вам, как сформировались принципы разработки библиотек в БЭМ-методологии. Надеемся, что многим это будет интересно и полезно. Итак, поехали.



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

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

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

• Изначально, React был нацелен на экспертов и ранних последователей
• Facebook открывает исходный код только тех продуктов, которые использует сам, т. е. не нацеленные на проекты-меньше-чем-Facebook
• Огромное количество гайдов по React совершенно разной сложности

Здесь и далее, я предполагаю, что вы уже знакомы с HTML, CSS и JavaScript.

На Хабре уже много писали о методологии БЭМ, выросшей в Яндексе. И мы решили, что пора системно рассказать о том, откуда она появилась и что сделало БЭМ таким, каким мы его знаем. Думаем, это будет интересно не только тем, кто уже использует БЭМ, но и тем, кто считает, что эта методология не подходит для их проектов. Возможно, они увидят, что мы решали проблемы, похожие на их собственные, и найдут что-то полезное для себя.



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

Звучная аббревиатура BEM пришла к нам из лабораторий Яндекса. Там, как и в случае с XSLT, применение BEM решили возвести в абсолют: под BEM'ом в Яндексе понимают целое семейство утилит и подходов, объединенных единой идеологией блочной архитектуры веб-приложений. Как любая тоталитарная система, BEM требует соблюдения строгих правил при разработке, не редко вступающих в конфликт со здравым смыслом небольших проектов, не сравнимых по ресурсам с Яндексом. И да, то самое чувство, когда читаешь официальные доки по BEM.

Однако, как часто бывает в процессе эволюции больших систем, под давлением интеллекта и безлимитных сроков рождается технологический алмаз, настолько же маленький и самостоятельный, насколько и ценный, который огранят уже другие. Да, BEM с его спасительной строгостью — это явное откровение. Каждый, кто на моих глазах причащался, мгновенно становился счастливым. Однако, после первой волны наслаждения приходит осознание, что второй подход к этому снаряду может порвать ментальные связки по всему объему мозга. И вот уже слышны жалобы на слишком большую сложность освоения, на чрезмерную многословность, на (внимание!) увеличение количества мегабайт в HTML и CSS, и кто знает на что еще, не относящееся к делу.

Соглашусь, трудно взять и начать писать BEM без разбега: и нотация глаз колет, и старые трюки не проходят, и думать приходится системно. И вообще, писали как-то годами без BEM'а и писать будем! А ведь для легкого и непринужденного преодоления порога вхождения нужно сделать всего два движения. Во-первых, понизить сам порог, смягчив BEM. И во-вторых, немного подтянуться самим. Тогда переход будет ровненьким и мы мягко вкатимся в эру читабельного и поддерживаемого CSS.

Сколько нужно времени, чтобы просто вывести на экран большой список, используя современные фреймворки?

Список на 2000 строк	ReactJS	AngularJS	Raw HTML	SAPUI5	$mol
Появление списка	170 ms	420 ms	260 ms	1200 ms	50 ms
Обновление всех его данных	75 ms	75 ms	260 ms	1200 ms	10 ms

Напишем нехитрое приложение — личный список задач. Какие у него будут характеристики?

ToDoMVC	ReactJS	AngularJS	PolymerJS	VanillaJS	$mol
Размер ( html + js + css + templates ) * gzip	322 KB	326 KB	56 KB	20 KB	23 KB
Время загрузки	1.4 s	1.5 s	1.0 s	1.7 s	0.7 s
Время создания и удаления 100 задач	1.3 s	1.7 s	1.4 s	1.6 s	0.5s

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

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

Связка HTML и CSS (CSS в большей степени) всегда казалась мне несколько «туманной», хуже всего поддающейся контролю и тестированию. Я придумывал для себя различные правила и пытался так или иначе стандартизировать свой подход, но не было ощущения, что «вот, это оно». Я несколько раз мельком знакомился с БЭМ (и не только), читал статьи на эту тему, но дальше чтения дело не заходило. Но чем дальше, тем сильнее было ощущение необходимости в наличии определенной строгой методологии. В конце концов, я решил попробовать внедрить БЭМ на одном из своих проектов, где без этого, на мой взгляд, было не обойтись. Речь идет о CMS, упрощенную страничку бекенда которой я приведу в качестве примера верстки:



Сразу хочу заметить, что БЭМ — это далеко не методология на все случаи жизни, и вопрос о необходимости ее применения в том или ином проекте следует рассматривать в частном порядке (в том числе исходя из того, нравится она вам или нет). Также, в силу того, что я не использовал предлагаемую специфическую файловую структуру или генерацию HTML, о них говорить не будем (позднее я все-таки разделил CSS-файл на отдельные части, соответствующие блокам, но этим решил пока ограничиться). Также, уже достаточно много (например, вот и вот) написано о достоинствах и недостатках этого подхода в целом, поэтому говорить об этом тоже не будем, я просто поделюсь своим опытом и размышлениями на эту тему, предполагая, что с сутью вы уже знакомы.