Why do you need BEM

Do you follow BEM, and how much is it needed outside of Yandex?

BEM stands for: block, element, modifier. This is such a set of abstractions, into which you can split the interface and develop everything in the same terms. As the site bem.info says, BEM offers uniform rules for writing code, helps scale and reuse it, and also increases productivity and simplifies teamwork.

Cool, yeah? But why do you need scalability and teamwork, if you are one typesetter on a project that does not claim Yandex popularity? To answer this question, you need to rewind the history of 10 years ago, when this approach was just started to be formulated.

The basis of what we now call BEM was the idea of ​​independent blocs, which Vitaly Kharisov formulated and presented in 2007 at the first Russian conference on the front end. It was so long ago that even the word "frontend" was not yet there, then it was called client-side.

The idea was to limit the possibilities of CSS for more predictable results. Use a minimum of global styles and make each individual page element a block with its own unique class and styles that completely describe it. Element and ID selectors, fragile nesting bundles - all this was replaced with simple class selectors. Each class in styles is a block. Thanks to this, the blocks can be easily reversed, put into each other and not be afraid of conflicts or influence.

#menu ul > li { color: old; } .menu-item { color: bem; } 

Then there appeared completely independent blocks (NSA), where the elements inside have their prefix with the name of the parent, and the state of the blocks again duplicate the class, but with a postfix. The approach acquired the features of modern BEM, one of which is the verbosity of classes.

 .block {} .block_mod {} .block__element {} .block__element_mod {} 

This verbosity guarantees the uniqueness of elements and modifiers within a single project. You follow the uniqueness of the block names yourself, but it is quite simple if each block is described in a separate file. Looking at such a class in HTML or CSS, you can easily say what it is and what it refers to.

Initially, the NSA, and then BEM, solved an important problem for the layout of any scale: predictable behavior and the creation of a reliable designer. You want your layout to be predictable? Here is Yandex too. This is also called “modularity” - Philip Walton wrote about it well in “CSS Architecture”, a link to the translation in the description.

A couple of years in Yandex finally formulated the BEM notation. Any interface was proposed to be divided into blocks. The inseparable parts of the blocks are the elements. Both have modifiers.

 <ul class="menu"> <li class="menu__item"></li> <li class="menu__item menu__item_current"></li> </ul> 

For example, the block search site. He can be in the cap and in the basement - it means a block. It has the required parts: the search field and the "find" button are its elements. If the field needs to be stretched to the full width, but only in the header, then the block or element that is responsible for this stretching is given a modifier.

For the complete independence of the blocks, it is not enough to name the classes correctly or isolate styles; you need to collect everything that applies to it. There is no common script.js or images folder with all site images in the BEM project. In one folder with each block is all that is needed for his work. This allows you to conveniently add, delete and transfer blocks between projects. Then, of course, all the resources of the blocks in the assembly are combined depending on the tasks of the project.

When BEM went beyond Yandex, at first it was perceived as magic and they tried to reproduce it literally, up to the prefixes b- in each block. Such a funny cargo cult.

 .b-block {} .b-block--mod {} .b-block__element {} .b-block__element--mod {} 

Some misunderstood the idea and even elements of the element appeared. Then enthusiasts took up the notation and one of the most popular appeared: the block is separated by two underscores, and the modifier - by two hyphens. Visually and simply - I write this myself.

 .block {} .block--mod {} .block__element {} .block__element--mod {} 

And why all these notations at all - I’m one coder on the project, remember? I remember. And I also remember how I used to make myself up to BEM: in each project I invented something so new. And then he opened the code a year ago and was surprised - what kind of idiot wrote it?

Take, for example, the Russian language. We write with the capital names of people, names and stuff like that? We write. So that it was easy to read it later: is it Nadya or hope for the best? Not to mention the punctuation marks and other useful agreements. Here the letter "e", for example, softens ... so what are we talking about? Yes, BEM.

Before BEM, there were projects with footcloths styles that should not be touched. They piled up over the years, layer upon layer, like wallpaper in an ancient communal flat. They were simply plugged in first, and then overwritten, which interfered. When you have a div { font-size: 80% } - it's not even funny anymore.

 /*   */ div { font-size: 80%; } 

BEM continued to develop in Yandex and grew beyond the limits of layout: there were redefinition levels, rich tools, a JS library for working with BEM classes, template engines and a whole BEM stack. BEM even came up with a gesture, but this is a completely different story specific to Yandex.

There were other methodologies: OOCSS Nicole Sullivan, Jonathan Snook SMACSS, BEM variations and whole frameworks. Even with us at an advanced intensive course, it was possible to choose any methodology for the layout of an educational project.

But only BEM survived and it can be called the de facto standard of modern interface design. And what is the final stage of evolution? Of course not. No matter how you automate, much in BEM has to be done by hand, and conflicts are possible.

Modularity and isolation of block styles can be solved even better. There are web components, CSS modules , a bunch of CSS-in-JS solutions and even, God forgive me, atomic CSS. But there is no single solution to the accumulated problems for the next 10 years, as BEM once became. What will it be? We'll see. I put on web components.

In the meantime, if you describe the interface by BEM, the code will be organized, predictable, expandable and ready for reuse. Not just for you, but for others.

Video version

Questions can be asked here .