A New Front-End Methodology: BEM (File System Representation For A Block)

• By Varvara Stepanova
• April 16th, 2012
• 15 Comments

BEM stands for “Block”, “Element”, “Modifier”. It is a front-end methodology: a new way of thinking when developing Web interfaces. This article will elaborate on the theory as well as the practice of building websites at Yandex—one of the leading internet companies in Russia.

Due to the length of this article, it was split into three parts:

• Part 1: BEM Principles
• Part 2: Blocks Reiteration
• Part 3: File System Representation For A Block

Unequivocal Placement of Code

File Naming

When a project is:

• Long-lived and under constant development.

If the development team:

• Consists of several people.
• Grows and changes.

Then being able to navigate the code base quickly is crucial.

Block code is easiest to find when it’s placed in files using the same naming scheme as the one we use for naming our entities:

menu.xsl
menu.js
menu.css

Expressing Blocks on a File System

There could be a task:

• To reuse some blocks from a previous project for a new one.

We want the procedure of block reuse to be as simple as possible—like simply copying the files, or using partial checkout of a repository from a “donor” project. In both cases, it is useful to have all of the files under the same directory:

menu/
  menu.xsl
  menu.js
  menu.css

File Structure of a Block

When working on a project we might need to change a block at some point.

A manager could ask:

• To change the color of the Current Menu Item, or
• To make the Menu react on hover.

A developer could ask their colleague:

• To help with Search Form styling for IE.

To understand where the relevant code is located, follow these (or similar) rules:

• Block code is placed in a separate directory.
• Directory name matches block name.
• Implementation is placed under this directory.
• Elements are placed in subdirectories under the block directory.
• Directory name matches element name.
• Implementation is placed under this directory.
• Modifiers are placed in subdirectories under the block directory.
• Directory name matches modifier name.
• Implementation is placed under this directory.
• File name includes both key and value of the modifier (again, for programmatic access).

Example
File structure of a Menu block:

menu/
  __item/
    _state/
      menu__item_state_current.css
      menu__item_state_current.xsl
    menu__item.css
    menu__item.xsl
  menu.css
  menu.js
  menu.xsl

Maintaining such file structure manually is, quite obviously, inconvenient. So we’ve developed BEM Tools to handle the burden. These tools help with creating the directory structure, placing files, generating placeholder content, etc.

Grouping Blocks in Directories

Big internet portals often need to reuse the same blocks across different websites.

There could be a task:

• To create the same Footer on all the portals’ websites, or
• To create a new project using blocks from the existing websites.

Working for a Web design agency often means that one has to use typical solutions for typical Web pages.

A project manager could ask you:

• To create an order page with a Web form as on the previous project.

We have to do these tasks while preferably avoiding copying blocks around manually. So it’s nice to have a repository of shared blocks that can be linked to a project. Blocks should then be united under a single directory for that.

Such a directory is usually called Blocks.

E.g.

blocks/
  foot/
  head/
  menu/
  page/
  search/

That directory can be linked to another project straight from the version control system, so that we can make changes to shared blocks in a single location.

Levels Of Definition

If a group of blocks (united under one directory) is linked to a project directly (via a partial checkout, svn:externals, etc.), then every change committed to these blocks influences all projects.

When developing a website based on an existing one, we might want:

• To enlarge the font in the Head on site A without affecting site B.
• To add animation when showing a drop-down menu.

To do so, we need to be able to define or redefine blocks in different technologies for a specific website only, or for certain pages only. This can be achieved using Definition Levels.

A Definition Level is a set of blocks grouped in one directory.

An implementation of every block from the library can be changed (or completely redefined) at project level.

From page-building process’ perspective:

• When building a page, we can set a list of levels (directories) to use their blocks on that page. E.g., build-page -l blocks-common -l blocks-my my-page.html

From the file structure point of view:

• A project can have any number of levels. But only the levels that are evaluated during the build will be present on the page. It is possible to specify different sets of definition levels for different parts of the website.

On the JavaScript side:

• We need to define dynamic behavior of a page in declarative style. Final behavior is gathered from different definition levels. E.g.,

/* blocks-common/dropdown/dropdown.js */
Block('dropdown', {
  init: function() {
    ...
  }
});

/* blocks-my/dropdown/dropdown.js */
Block('dropdown', {
  init: function() {
    this.__base();
    ...
  }
});

From the viewpoint of a template engine:

• To be able to not only define, but to redefine a template, one needs to apply a preceding template implementation.
  E.g., for XSL:

<xsl:template match="b:head">
  <div> <!-- Node for extra design -->
    <xsl:apply-imports/>
  </div>
</xsl:template>

From the architectural point of view:

• When developing a portal of several websites, we can extract a block library that serves as one of the definition levels for all the websites which are part of the portal. The blocks for a specific website will form another level.
• The same repo can hold blocks of both desktop and mobile versions.
  Such a project will have the following levels: common, mobile, desktop. Different combinations of these levels give the resulting implementation, required by specific pages.

Open source block library bem-bl (in development) is an example of having several definition levels in one repository.

Building A Page

Working in terms of blocks means having a Subject-Matter Abstraction. This abstraction is for developers only, and browsers will get a compiled version of the code.

So we have Code For People and Code For Browsers—they are not the same.

• Programmers code blocks—browsers get the code for the whole page.

To turn Code For People into Code For Browsers we Build a page.

Building A Page means generating HTML, CSS, and JavaScript code from a page declaration (written in XML or JSON) by applying implementations of declared blocks.

On the CSS side:

• All CSS files are combined into a “single page” CSS file.
  Despite the fact that CSS for every block, element or modifier is stored in separate files, we don’t have to link these files to the page as is. It’s possible to collect all the required CSS implementations into one file.
  This also solves the well-known “number of imports” issue in IE, and decreases the number of HTTP requests. For combining CSS we use borschik.
• Browser gets minimized code.
  When building CSS, we can minimize and optimize CSS code using the CSSO utility, for example.
• Each browser can get CSS code written especially for it.
  It is also possible to divide CSS implementations for different browsers and deliver only the code needed for each browser.
  setochka—currently in prototype can be used for that.

From the JavaScript point of view:

• Similarly to CSS, JavaScript files can be combined into one.

From the template engine’s point of view:

• Only needed templates are included.
  Final set of templates that are used for displaying a page includes only the templates for required blocks. This boosts template performance and reduces the likelihood of side effects.

From the viewpoint of development process:

• Robots serve people (not the other way around).
  Developer writes code as they see fit. “Robots” take (some) care of performance by optimizing the code (together with making it unreadable) when building a page.

In terms of work organization:

• Division of labor.
  We have developers working on the core framework (compilers, tools, performance); library developers, who maintain the block library; application developers, who develop websites using the framework.

We use BEM tools to build pages.

How to Automate the Building Process?

The usage of bem tools requires to run several commands for each page whenever page input data or blocks implementation are changed. As a result of these commands, you get CSS and JavaScript files for the page, page’s template, and if you are developing static pages, the HTML code of your page.

To avoid running these commands manually, there is also the GNUmakefile, which was written for a project that includes the instructions on how to build pages.
You can find an example of such a file in the test project bem-bl-test.

But the usage of GNU Make has a list of problems:

• You have to run it every time you have changed something.
• Every time you run gmake, it reads the information from a disk. So the compilation process could not be fast.
• The pages you build not only depend on the content of block files, but on their file structure as well. But it’s impossible to write a gmake goal dependency in these terms.

So we’d like to create something to replace GNU Make for the process of page building. This will be both a development server and a tool to build production files. Bem Server will be run in a project root directory, and give HTTP response with the page files built (so you won’t need to run gmake manually after each change).
Besides, it will be able to watch the files (the adding and removing of them) via fs.FSWatcher that help to chache results efficiently.

BEM Server is a subcommand of bem-tools. Currently it can run an HTTP server, apply BEMhtml templates to BEMjson data and inline CSS imports using borschik utility.

Real Examples

Yandex is a large (mostly Russian) company that use BEM methodology to develop its services.

BEM methodology does not request that you use a certain framework. You also don’t have to use BEM for all the technologies you have on your pages (but that would be the most efficient).

All the services of Yandex have BEM in their CSS, JavaScript code or XSL templates for their pages. E.g.,

• Yandex.Maps
• Yandex.Images
  This is a service for searching images in the Internet.
• Yandex.Video
  This is a service for both hosting and searching images.
• Yandex.Jobs
• Turkish Yandex

Some services don’t use XSL templates, building their pages with our newest template product, Bemhtml template engine which was mentioned above. These are the following services:

• Yandex Search
  or Yandex Search in English
• Mobile Apps Search
  This website is to look under smartphones.

There are also other companies that use BEM methodology.

For example, the guys at Mail.ru partly use BEM for their services. Some blocks on their pages are BEM-based in terms of CSS code. They also have their own C++ template engine, and write block templates according to this methodology.

More examples:

• Rambler.News
• HeadHunter
• TNK Racing Team

You also may be interested in websites that use bem-bl block library (in development):

• Mikhail Troshev vCard
  Source code is hosted at GitHub: https://github.com/mishanga/bem-vcard
• BEM based web form with JZ validation

Related Links

Libraries

• An open source block library bem-bl (in development).

Tools

• Tools for working with files according to BEM methodology.
• Borschik
  A utility for building static files into one.
• Setochka, a working prototype
  A tool for dividing CSS into several browser-specific files.
• CSSO
  A utility that performs advanced, structural optimizations of CSS code.

Additional Information

• How to use BEM! outside Yandex (screencast presentation).
• Presentations and workshops video (in Russian).
• BEM club on Ya.Ru (in Russian).
• BEM on Facebook.

Smashing Special: A Three-Part Article

Due to the length of the article, it was split into three parts:

• Part 1: BEM Principles
• Part 2: Blocks Reiteration
• Part 3: File System Representation For A Block

(jvb)