Перевод статьи Макса

gistfile1.html

Разработка интерфейсов уже не про отдельные фреймворки. Все инструменты доступны, и наша задача сводится только к выбору. А чтобы 
сделать правильный выбор, нужно начать с общего подхода, с <strong>методологии</strong>. Но большинство методологий разработаны
большими компаниями. Так ли они применимы в маленьких или нужно переизобретать их, чтобы применять в нашей ситуации?

Скорее всего вы уже знаете об одной из таких методологий, разработанной <a href="http://yandex.ru">Яндексом</a>б это
<a href="http://bem.info">БЭМ</a>. БЭм утверждает, что трех сущностей — <strong>б</strong>локов, <strong>э</strong>лементов и
<strong>м</strong>одификаторов — хватает для того, чтобы написать HTML и CSS, задать коду структуру, использовать компонентный
подход и масштабировать проект до самого высокого уровня.

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

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


<figure><img title="" src="http://www.smashingmagazine.com/wp-content/uploads/2014/06/bem-methodology-opt.png" alt="" width="500" height="316" /></figure>Я
мысленно возвратился к этому вопросу год назад, когда переехал в Берлин для работы в компании меньшего размера — Deltamethod.
Планы на разработку у нас были смелые, и мы решили попробовать немного БЭМа. Хотелось получить те же плюшки, что были у
Яндекса: реиспользование кода, живой codestyle, масштабируемость и быструю разработку. Также мы хотели сохранить
используемые инструменты и переписывать код постепенно, а не с писать весь сервис с нуля.

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

<h3>Основы БЭМ</h3>

Давайте начнем с того, чтобы вспомнить основы.

В то время как утверждается, что семантика — это фундамент веб разработки, различные frontend технологии не используют одну и ту же
семантическую модель. В HTML современное приложение — это нагромождение тегов div. CSS в принципе не предгалает какой-то
структуры. Высокоуровневые JavaScript компоненты используют абстракции, но они никак не связаны с CSS разметной. А с точки зрения
UX интерфейсы описываютсяя терминами вообще далекими от техническое реализации. Самое время для БЭМ, ведь это
общая семантическая модель для разметки, стилей, кода и UX. Давайте посмотрим поближе.

<h4>Блоки</h4>
Блок — это независимая сущность <strong>со своим собственным смыслом</strong>, он представляет на странице отдельный "кирпичик"
интерфейса.

Например, блоками могут быть:
<ul>
	<li>заголовок,</li>
	<li>кнопка,</li>
	<li>навигационное меню.</li>
</ul>
Чтобы задать блок, вам нужно придумать ему имя и определить его назначение. В интерфейсе может одновременно присутствовать
несколько экземпляров одного и того же блока (например, разные кнопки или несколько меню).

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

<h4>Элементы</h4>
Элемент — это <strong>часть блока</strong>, связанная с ним и по смыслу, и функционально. Без блока, к которому он относится,
элемент не имеет смысла. Но не у всех блоков должны быть элементы.

Примеры элементов:
<ul>
	<li>навигационное меню (блок), содержащее пункты меню (элементы),</li>
	<li>таблица (блок), внутри которой строки, ячейки и заголовки (элементы).</li>
</ul>
У элементов тоже есть названия. Если внутри блока несколько одинаковых элементов, то они идут под одним именем (например,
ячейки таблицы или пункты списка). Элементы определяются <strong>по смыслу</strong>, и не обязательно совпадают
с HTML структурой — HTML может быть сложным, но это всё один элемент.

<h4>Модификаторы</h4>
Модификаторы — это флаги у блоков или элементов, они определяют свойства или состояния. Модификаторы могут быть булевы,
(например, <code>visible: true</code> или <code>false</code>) или парами ключ-значение (code>size: large</code>,
<code>medium</code>, <code>small</code>). Это чем-то похоже на атрибуты в HTML, но всё-таки не то же самое. У сущности может
быть несколько модификаторов, если они описывают разные вещи.

<h4>Блоки в DOM</h4>
Как использовать БЭМ, если мы всё ещё вынуждены писать HTML? Нужно соглашение об именовании, которое свяжет
DOM узлы с БЭМ сущностями.

Для обозначения такой связи БЭМ использует CSS классы. При этом блоки, элементы и модификаторы не столбят за собой DOM
узлы, на одном теге может быть сразу несколько блоков или элемент блока может быть объединен с контейнером другого блока.

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

<h4>Дерево БЭМ (BEM tree)</h4>

Формируя документ из БЭМ сущностей, начиная с корневого блока (<code>&lt;body&gt;</code> или даже <code>&lt;html&gt;</code>), заканчиая самыми
глубоко вложенными блоками, вы создаёте семантический слой поверх существующей DOM структуры.

Этот слой называется БЭМ деревом (или BEM tree).

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

<h3>Первые шаги</h3>

Если вы уже задумываетесь, а не попробовать ли БЭМ, возникает закономерный вопрос: "Как мигрировать на БЭМ
существующий проект, можно ли это сделать постепенно?"

Конечно, можно. Давайте начнем с того, чтобы выделить несколько блоков. Мы будем касаться только семантики, а конкретные
технологии (такие как CSS и JavaScript) затронем позже.

Как вы помните, только самостоятельная вещь может быть блоком.

Например, заголовки – это блоки. У них нет внутренних элементов, но уровни заголовков (от самого большого до самого маленького)
могут быть определены как модификаторы вида ключ-значение.

Если позже понадобятся ещё уровни, мы определим дополнительные модификаторы. Тут я скажу, что разработчики HTML4
были не правы, изобретая <code>&lt;h1&gt;</code>  ...<code>&lt;h6&gt;</code>.  Они сделали разызные теги,
тогда как это должны были быть модификаторы. В HTML5 это пытаются исправить с секционными элементами,
но браузеры ещё долго будут поддерживать существующий сейчас вариант.

Скажем, мы получили такое:
<pre><code class="language-markup">
BLOCK heading
MOD level: alpha, beta, gamma
</code></pre>

В качестве второго примера можно взять форму, её контролы — это блоки (и поля ввода, и кнопки). Хотя сейчас в 
HTML беспорядок. Разные по сымслу вещи (поля ввода, радио кнопки и checkbox'ы) объединены в один тег
<code>&lt;input&gt;</code> , a другие (кажущиеся похожими) определены разными тегами
<code>&lt;select&gt;</code> и <code>&lt;textarea&gt;</code>. А другие вещи, такие как метки <code>&lt;label&gt;</code>
и автоматические подсказки <code>datalist</code> должны были быть элементами этих блоков, потому что  по отдельности
в них нет смысла.

Посмотрим, можно ли это исправить:
<pre><code class="language-markup">
BLOCK text-input
MOD multiline
MOD disabled
  ELEMENT text-field
  ELEMENT label
</code></pre>
Поле ввода нужно для того, чтобы туда можно было написать текст. Если же нам нужен многострочный текст,
семантически ничего не меняется, поэтому <code>multiline</code> — это только модификатор. В HTML у этих двух случаев
по техническим причинам разметка будет разной, но это нормально — сейчас мы сосредоточены на определении семантики, а не
конкретной реализации. Ещё у блока есть элементы <code>textfield</code> и <code>label</code>. Позже может понадобиться
добавить и другие элементы, такие как иконка статуса, место для сообщения об ошибке и автоподсказка.

<pre><code class="language-markup">
BLOCK checkbox
  ELEMENT tick-box
  ELEMENT label
</code></pre>
<pre><code class="language-markup">
BLOCK radio
  ELEMENT radio-button
  ELEMENT label
</code></pre>

Эти два блока довольно очевидны. По-прежнему есть элемент <code>&lt;label&gt;</code> и элемент, представленный тегом
<code>&lt;input&gt;</code>.

<pre><code class="language-markup">
BLOCK select
MOD disabled
MOD multiple
  ELEMENT optgroup
  ELEMENT option
    MOD disabled
	MOD selected
</code></pre>

В случае select, метки label не нужны, а все остальное более или менее похоже на обычный контрол select. Технически можно
реиспользовать существующий <code>&lt;select&gt;</code> и его структуру. Обратите внимание, что и у блока <code>select</code>, и
у его элемента <code>option</code> может быть модификатор <code>disabled</code>. Важно, что это <strong>разные</strong>
модификаторы: первый выключает весь контрол целиком, а второй (кстати, хороший пример модификатора элемента) выключает только
конкретный <code>option</code>.

Попробуйте и в своём проекте найти такие примеры блоков.

Для первого раза это может быть непросто. Так что, если нужна помощь, о ней можно
<a href="mailto:[email protected]">попросить команду БЭМ</a>!

<h3>Let Your CSS Speak Out Loud</h3>
Perhaps you’ve heard a lot about BEM as a way to optimize CSS and are wondering how it works?

As mentioned, BEM uses CSS class names to store information about blocks, elements and modifiers. With a simple naming convention, BEM teaches your CSS to speak, and it adds meaning that makes it simpler, faster, more scalable and easier to maintain.
<h4>BEM Naming Conventions for CSS</h4>
Here are the prerequisites:
<ul>
	<li>Keep the names of blocks, elements and modifiers short and semantic.</li>
	<li>Use only Latin letters, dashes and digits.</li>
	<li>Do not use underscores (<code>_</code>), which are reserved as “separator” characters.</li>
</ul>
Block containers get a CSS class of a prefix and a block name:
<pre><code class="language-markup">
.b-heading
.b-text-input
</code></pre>
That <code>b-</code> prefix stands for “block” and is the default in many BEM implementations. You can use your own — just keep it short. Prefixes are optional, but they emulate much-anticipated (and missing!) CSS namespaces.

Element containers within a block get CSS classes consisting of their block class, two underscores and the element’s name:
<pre><code class="language-markup">
.b-text-input__label
.b-text-input__text-field
</code></pre>
Element names do not reflect the block’s structure. Regardless of nested levels within, it’s always just the block name and the element name (so, never <code>.b-block__elem1__elem2</code>).

Modifiers belong to a block or an element. Their CSS class is the class name of their “owner,” one underscore and a modifier name:
<pre><code class="language-markup">
.b-text-input_disabled
.b-select__option_selected
</code></pre>
For a “boolean” modifier, this is enough. Some modifiers, however, are key-value pairs with more than one possible value. Use another underscore to separate the values:
<pre><code class="language-markup">
.b-heading_level_alpha
</code></pre>
Modifier classes are used together with the block and element class, like so:
<pre><code class="language-html">
&lt;div class="b-heading b-heading_level_alpha"&gt;BEM&lt;/div&gt;
</code></pre>
<h3>Why Choose BEM CSS Over Other Approaches</h3>
<h4>One Class to Rule Them All</h4>
CSS sometimes depends a lot on the document’s structure — if you change the structure, you break the CSS. With BEM, you can drop tag names and IDs from your CSS completely, using only class names. This mostly frees you from structural dependencies.
<h4>Specificity Problems Solved</h4>
Big chunks of CSS are hard to maintain because they keep redefining themselves unpredictably.

This issue is called CSS specificity. The original problem is that both tag names and element IDs change selector specificity in such a way that if you rely on inheritance (the most common thing to expect from CSS), then you can only override it with selectors of the same or higher specificity. BEM projects are least affected by this problem. Let’s see why.

Let’s say you have a table with these style rules:
<pre><code class="language-css">
td.data { background-color: white }
td.summary  { background-color: yellow }
</code></pre>
However, in another component, you need to redefine the background of a particular cell:
<pre><code class="language-css">
.final-summary { background-color: green }
</code></pre>
This wouldn’t work because <code>tag.class</code> always has a higher specificity than just <code>.class</code>.

You would add a tag name to the rule to make it work:
<pre><code class="language-css">
td.final-summary { background-color: green }
</code></pre>
Because BEM provides unique class names for most styles, you would depend only on the order of rules.
<h4>Bye-Bye Cascade?!</h4>
Nested CSS selectors aren’t fast enough in old browsers and can create unintended overrides that break the styles of other elements. Eliminating a lot of the cascade from CSS is possible with BEM.

How is this possible, and why is it important? Isn’t the cascade <em>supposed</em> to be there? Isn’t it the “C” in CSS)?

As you know, every BEM CSS class is unique and self-sufficient. It does not depend on tags or IDs, and different blocks never share class names. That’s why you need only a single class name selector to do the following:
<ul>
	<li>style a block container,</li>
	<li>style any block element,</li>
	<li>add style extras and overrides with a modifier.</li>
</ul>
This covers most of your styling needs, all with just one class selector. So, it’s mostly about single-class selectors now, and they are extremely fast. To apply a selector, the browser starts with an initial (broader) set of elements (usually determined by the rightmost part of a selector), and then gradually reduces the set by applying other parts until only matching elements remain. The more steps needed, the more time it takes, which is why you can hardly beat single-class selectors for speed.

CSS is rarely a performance bottleneck on small pages, but CSS rules must be reapplied with every document reflow. So, when your project grows, things will get slower at some point. According to usability science, 250 milliseconds is the perception limit for “instant.” The faster your selectors are, the more room you have to manoeuvre to keep that “blazing fast” feeling for your users.

So, no cascade?! Well, almost. In some cases, you might need two class names in a selector — for example, when a block modifier affects individual elements:
<pre><code class="language-css">
.b-text-input_disabled .b-text-input__label
{
   display: none;
}
</code></pre>
The nice thing is that any rule that redefines this one will likely depend on another modifier (because of the unified semantics!), which means that specificity is still the same and only the rule order matters. Surely, we can invent more cases that require even more cascading (internal element dependencies, nested modifiers, etc.). While the BEM methodology allows for that, you’ll hardly ever need it in real code.
<h4>Absolutely Independent Blocks</h4>
If blocks depend on each other’s styles, how do we express that in CSS? The answer is, they shouldn’t. Each block must contain all styles necessary for its presentation. The overhead is minimal, but this ensures that you can move blocks freely within a page or even between projects without extra dependencies. Avoid project-wide CSS resets for the same reason.

This is not the case for elements because they are guaranteed to stay within their parent block and, thus, inherit block styles accordingly.
<h3>Alternative BEM Naming Conventions</h3>
A number of alternative BEM naming conventions exist. Which should we use?

BEM’s “official” naming convention for CSS is not the only one possible. <a href="http://nicolasgallagher.com/about-html-semantics-front-end-architecture/">Nicolas Gallagher once proposed</a> some improvements, and other adopters have, too. One idea is to use attributes to represent modifiers, and CSS prefixes aren’t “standardized” at all.

The biggest advantage of the syntax proposed by the team behind BEM is that it’s the one supported in open-source tools distributed by Yandex, which you might find handy at some point. In the end, the methodology is what matters, not the naming convention; if you decide to use a different convention, just make sure you do it for a reason.
<h3>Semantic JavaScript: BEM-Oriented Code</h3>
How do you apply the BEM model to JavaScript code?

Many publishers and authors view BEM as a naming convention only for CSS, but that brings only half of the benefits to a project. The BEM methodology was designed to fix (i.e. polyfill) non-semantic DOM structures at all levels (HTML, CSS, JavaScript, templates and UX design), similar to how jQuery “fixes” broken DOM APIs. HTML was designed as a text markup language, but we use it to build the most interactive interfaces around. Experimental efforts such as Web Components strive to bring semantics back into our markup and code, but BEM can be used in a full range of browsers now, while retaining compatibility with future approaches, because it does not depend on any particular API or library.

We’ll go through a development paradigm using as little code as possible. It will be really high-level and abstract, but the abstractness will help us to understand the idea more clearly. You’ll notice another term in the heading above: “BEM-oriented code.” Before explaining what’s behind that, let’s go over some ideas that are useful to know when applying BEM to JavaScript.
<h4>Learning to Declare</h4>
The first step is to embrace a <strong>declarative paradigm</strong>. Declarative programming is an approach that concentrates on the “what,” not the “how.” Regular expressions, SQL and XSLT are all declarative, and they specify not the control flow, but rather the logic behind it. When doing declarative programming, you’d start by describing a set of <strong>conditions</strong>, each of them mapped to specific <strong>actions</strong>.

In BEM, conditions are represented by <strong>modifiers</strong>, and <strong>any action can only happen on a block or element</strong>. The code examples in this article will use the <code>i-bem.js</code> framework, written and open-sourced by Yandex, but your favorite framework might be able to do similar or better things because declarative programming is not tied to a specific implementation.
<pre><code class="language-javascript">
BEM.DOM.decl('b-dropdown', {
   onSetMod: {
      disabled: function(modName, modVal) {
         this.getLabel().setMod('hidden', 'yes');
         if (modVal === 'yes') {
            this.getPopup().hide();
         }
      },

      open: {
         yes: function() {
            this.populateList();
         }
      }
   },
   /* … */
</code></pre>
The code snippet above defines actions for two modifiers on a <code>b-dropdown</code> block.

These are similar to event handlers, but all states get immediately reflected in the CSS. Modifiers are still stored as class names on the corresponding block and element entities.

Enabling and disabling different key bindings on a <code>b-editor</code> block is another example of how to use modifiers:
<pre><code class="language-javascript">
BEM.DOM.decl('b-editor', {
   onSetMod: {
      hotkeys: {
         windows: function() {
            this.delMod('theme');
            this.loadKeyMap('windows');
         },
         emacs: function() {
            this.setMod('theme', 'unix');
            this.loadKeyMap('emacs');
            enableEasterEgg();
         }
      }
   },
   onDelMod: {
      hotkeys: function() {
         this.clearKeyMaps();
         this.delMod('theme');
      }
   }
   /* … */
</code></pre>
In this example, we see how modifiers bring logic to our transitions in state.
<h4>Methods</h4>
With a declarative approach, methods are not always “tied” to a component automatically. Instead, they, too, can be <strong>declared</strong> to belong to some instances under certain circumstances:
<pre><code class="language-javascript">
BEM.DOM.decl({ name : 'b-popup', modName : 'type', modVal : 'inplace' }, {
   appear: function() {
      // makeYouHappy();
   }
});
</code></pre>
This method is defined only for blocks that have the specific <code>type</code> modifier: <code>inplace</code>.

As in classic object-oriented programming, you can extend semantically defined methods by providing even more specific <strong>declarations</strong> and reuse the original code if necessary. So, both overrides and extensions are possible. For example:
<pre><code class="language-javascript">
BEM.DOM.decl({'name': 'b-link', 'modName': 'pseudo', 'modVal': 'yes'}, {
   _onClick : function() {
      // runs the basic _onClick defined
      // for all b-link instances
      this.__base.apply(this, arguments);

      // redefine the appearance from within CSS,
      // this code only gives you a semantic basis! 
      this.setMod('status', 'clicked');
   }
});
</code></pre>
As specified by this definition, the extended <code>_onClick</code> method runs only on <code>b-link</code> instances with a <code>_pseudo_yes</code> modifier. In all other cases, the “original” method is implemented.

Semantics will slowly migrate from your markup (where it’s not needed anymore) to your code (where it supports modularity and readability, making it easier to work with).
<h4>“… Sitting in a (BEM) Tree”</h4>
What is the practical use of a declarative approach if it is way too abstract? The idea is to work with a BEM tree, which is semantic and controlled by you, instead of a DOM tree, which is tied to the markup and specifics of implementation:
<pre><code class="language-javascript">
BEM.DOM.decl('b-checkbox-example', {
   onSetMod: {
      js: {
         inited: function() {
            var checkbox = this.findBlockInside({
               blockName: 'b-form-checkbox',
               modName: 'type',
               modVal: 'my-checkbox'
            });
            this.domElem.append('Checkbox value: ' + checkbox.val());
         }
      }
   }
}
);
</code></pre>
Other APIs exist, like <code>this.elem('name')</code> and <code>this.findBlockOutside('b-block')</code>. Instead of providing a complete reference, I’d just highlight BEM trees as the API’s foundation.
<h4>Modify Modifiers to Control Controls</h4>
The previous section leaves the important subject of <strong>application state changes</strong> unaddressed. When app states are declared, you need a way to perform transitions. This should be done by operating on a BEM tree, with the help of modifiers. BEM modifiers can be set directly on DOM nodes (as class names), but we cannot effectively monitor that (for technical reasons). Instead, <code>i-bem.js</code> provides a simple API that you can use as inspiration:
<pre><code class="language-javascript">
// setter
this.setMod(modName, modVal);
// getter
this.getMod(modName);
// check for presence
this.hasMod(modName, modVal);
// toggle
this.toggleMod(modName, modVal);
// remove modifier
this.delMod(modName);
</code></pre>
Thus, we can internally hook into the modifier change call and run all of the actions specified for this particular case.
<h4>BEM-Oriented Code Explained</h4>
Many JavaScript libraries provide enough power to support the BEM methodology without introducing a completely new tool chain. Here’s a check list to see whether the one you’re looking at does so:
<ul>
	<li><strong>Embraces a declarative approach</strong></li>
	<li><strong>Defines your website or app in BEM’s terms</strong>
Can many of the project’s existing entities be “mapped” to blocks, elements and modifier properties?</li>
	<li><strong>Allows you to drop the DOM tree for the BEM tree</strong>
Regardless of any particular framework API, wipe out as much of the raw DOM interaction as you can, replacing it with BEM’s tree interaction. During this process, some of the nodes you work with will be redefined as blocks or elements; name them, and see how the true semantic structure of your application reveals itself.</li>
	<li><strong>Uses modifiers to work with state transitions</strong>
Obviously, you shouldn’t define all states with modifiers. Start with the ones that can be expressed in CSS (to hide and reveal elements, to change style based on states, etc.), and clean your code of any direct manipulation of style.</li>
</ul>
If your framework of choice can do this, then you are all set for BEM-oriented code.

jQuery users could try these lightweight plugins to extend their code with BEM methods:
<ul>
	<li><a href="http://xslc.org/jquery-bem/">jQuery BEM</a> plugin</li>
	<li><a href="http://github.com/ingdir/jquery-bemhelpers/">jQuery BEM Helpers</a> (<code>setMod</code> and <code>getMod</code>)</li>
</ul>
<h3>From A Naming Convention To A Style Guide</h3>
If you work a lot with designers, your team would also benefit from a BEM approach.

Imagine that you had a style guide created by a Real Designer™. You would usually get it as a PDF file and be able to learn everything about the project’s typefaces, color schemes, interface interaction principles and so on. It serves perfectly as a graphic book that is interesting to look at in your spare time. However, it would be of little to no use to most front-end developers — at the level of code, front-end developers operate with totally different entities.

But what if you and the designer could speak with each other using the same language? Of course, this would require some training, but the benefits are worth it. Your style guide would be an interactive <strong>block library</strong>, expressed in BEM terms. Such a library would consist of blocks that are ready to be used to build your product.

Once the designer is familiar with BEM’s terms, they can iterate towards designing <strong>blocks</strong> and <strong>elements</strong>, instead of “screens.” This will also help them to identify similar UI parts and unify them. Modifiers help to define visual variations (i.e. which apply to all blocks) and states (i.e. for interactive blocks only). The blocks would be granular enough to enable you to make an early estimation of the amount of work that needs to be done. The result is a specification that fully covers all important states that can be reused with other screens or pages. This eventually allows you to mock up interfaces as wireframes or sketches, because all of the building blocks have already been defined. More importantly, this model maps directly to the code base, because the blocks, elements and modifiers defined by the designer are essentially the <strong>same</strong> blocks, elements and modifiers that the developer will implement. If you have been using BEM in your project for some time, then certain blocks are probably already available.

The biggest change, however, is closing the gap between screen and code by operating on the same entities in the UI design and development. Like the famous Babel fish, BEM enables you to understand people who have no idea how your code works.

On a bigger team, working on individual blocks is easier because it can be done in parallel, and big features do not end up being owned by any one developer. Instead, you share the code and help each other. The more you align the JavaScript HTML and CSS with BEM, the less time you need to become familiar with new code.
<h3>BEM As High-Level Documentation</h3>
Despite all advice, developers still don’t write enough documentation. Moving projects between developers and teams is non-trivial. Code maintenance is all about minimizing the time a developer needs to grasp a component’s structure.

Documentation helps a lot, but let’s be honest, it usually doesn’t exist. When it does exist, it usually covers methods, properties and APIs, but hardly anything about the flow of components, states or transitions. With minimally structured BEM-oriented code, you will immediately see the following:
<ul>
	<li>the elements you’re dealing with,</li>
	<li>other blocks you depend on,</li>
	<li>states (modifiers) that you need to be aware of or support,</li>
	<li>element modifiers for fine-grained control.</li>
</ul>
Explaining with examples is easier. What would you say about the following block?
<pre><code class="language-markup">
b-popup
  _hidden
  _size _big
        _medium
	_large
  _dir _left
       _right
	_top
	_bottom
  _color-scheme _dark
                _light

	__anchor-node
	__popup-box
	__close-btn
	__controls
	__ok
	__cancel
</code></pre>
By now, <em>you</em> can tell <em>me</em> what this block is about!

Remember, you’ve seen zero documentation. This block could be a structure that you’ve defined in a CSS preprocessor or a YAML meta description.
<h3>BEM And File Structure</h3>
In a growing project, an inconsistent file structure could slow you down. The structure will only become more complex and less flexible with time. Unfortunately, tools and frameworks do not solve the problem because they either deal with their own internal data or offer no specific structure at all. You and only you must define a structure for the project. Here, BEM can help as well.
<h4>Block Library</h4>
A block’s folder is the basis of all BEM-based file structures. Block names are unique within the project, as are folder names. Because blocks do not define any hierarchies, keep block folders as a flat structure:
<pre><code class="language-markup">
/blocks
  /b-button
  /b-heading
  /b-flyout
  /b-menu
  /b-text-field
</code></pre>
Libraries and other dependencies may be defined as blocks, too. For example:
<pre><code class="language-markup">
/blocks
  …
  /b-jquery
  /b-model
</code></pre>
Inside each folder, the easiest arrangement would be to give each “technology” a distinct file:
<pre><code class="language-markup">
/b-menu
  b-menu.js
  b-menu.css
  b-menu.tpl
</code></pre>
A more advanced approach would be to store some definitions of elements and modifiers in separate subfolders and then implement in a modular way:
<pre><code class="language-markup">
/b-menu
  /__item
	b-menu__item.css
	b-menu__item.tpl
  /_horizontal
    b-menu_horizontal.css
  /_theme
    /_dark
	  b-menu_theme_dark.css
	/_light
	  b-menu_theme_light.css

  b-menu.css
  b-menu.js
  b-menu.tpl
</code></pre>
This gives you control, but it also requires more time and effort to support the structure. The choice is yours.
<h4>Redefinition Levels</h4>
What if you need to extend the styles and functionality of components or share code between projects without changing (or copying and pasting) the original source?

Big web apps, sections and pages could be significantly different, as could be the blocks they use. At the same time, a shared block library often has to be extended, individual items redefined and new items added. BEM addresses this with the concept of redefinition levels. As long as you’ve chosen a file structure, it should be the <strong>same for any block</strong>. That’s why several block libraries can be on different levels of an application.

For example, you could have a common block library as well as several specific libraries for individual pages:
<pre><code class="language-markup">
/common
  /blocks
    /b-heading
	/b-menu
	…

/pages
  /intro
    /blocks
	  /b-heading
	    b-heading_decorated.css
	  /b-demo
	  /b-wizard
	  …
</code></pre>
Now, <code>/common/blocks</code> will aggregate blocks used across the whole app.

For each page (as for <code>/pages/intro</code> in our example), we define a new <strong>redefinition level</strong>: A specific library, <code>/pages/intro/blocks</code>, adds new blocks and extends some common ones (see the extra <code>_decorated</code> modifier for the common <code>b-heading</code> block).

Your build tool can use these levels to provide page-specific builds.

Separation of libraries can be based on the form factors of devices:
<pre><code class="language-markup">
/common.blocks
/desktop.blocks
/mobile.blocks
</code></pre>
The <code>common</code> library stays “on top,” while the <code>mobile</code> or <code>desktop</code> block bundle extends it, being the next redefinition level. The same mechanism applies when several different projects need to share blocks or when a cross-project common block library exists to unify the design and behavior across several services.
<h4>The Build Process</h4>
We’ve ended up with many small files, which is good for development but a disaster for production! In the end, we want all of the stuff to be loaded in several big chunks. So, we need a build process.

Yandex has an open-source build tool, <a href="http://bem.info/articles/borschik">Borschik</a>, which is capable of building JavaScript and CSS files and then compressing and optimizing them with external tools, such as <a href="https://github.com/mishoo/UglifyJS">UglifyJS</a> and <a href="https://github.com/css/csso">CSS Optimizer</a>. Tools like <a href="http://requirejs.org">RequireJS</a> can also facilitate the building process, taking care of dependency tracking.

For a more comprehensive approach, have a look at <a href="http://bem.info/tools/bem/">bem-tools</a>.

The clearest lesson I’ve learned from BEM is not to be afraid of granularity, as long as you know how to build the whole picture.
<h3>Beyond Frameworks</h3>
For a while, I was pretty skeptical that BEM is suitable for small projects. My recent experience in a startup environment proved me wrong. BEM is not just for big companies. It works for everyone by bringing unified semantics across all of the front-end technologies that you use.

But that is not the biggest impact of the BEM methodology on my projects. BEM enables you to see beyond frameworks. I remember times when people seriously discussed the best ways to bind event handlers to elements, and when DOM libraries competed for world dominance, and when frameworks were the next big buzz. Today, we can no longer depend on a single framework, and BEM takes the next step by providing a design foundation, giving us a lot of freedom to implement.

Visit the <a href="http://bem.info">BEM</a> website for extra resources, GitHub links, downloads and articles.

Long story short, BEM it!

<em>(al)</em>