Mono has closed its doors. Read more in our blogpost.

Go to main content

Learning to Love BEM

I have to admit: when I first heard about BEM, I thought it was a bad idea. Why make your CSS naming so complicated? Surely you can get by with simple class names like .form-group or .accordion. Why do you have to get all crazy with classes like .accordion__child and .accordion__child--highlighted?

In a project in January, I worked with Jelle who was using BEM-style syntax in his code. At first I was hesitant but since he was the lead HTML/CSS guy on the project I let him do his thing.

After learning more about BEM I am convinced: the method really has its merits. It is mostly useful in the context of a large scale web application with a lot of components.

Think about an admin interface with a lot of widgets and screens with different states. Think about software that has to be stable, with many people working on different CSS components. Here, BEM makes a lot of sense.

The logic for BEM (Block – Element – Modifier) is:

  • There is a block e.g. .my-element
  • There is a element e.g. .my-element__sub-element (the 2 underscores denote sub elements)
  • There might be a modifier e.g. .my-element__sub-elelement—highlighted (the 2 hyphens denote a modifier state).

A longer explanation is here.

This has some advantages:

  • Because of the above logic, it is immediately apparent “what” a CSS class means
  • Every element is namespaced, making find and replace actions across the whole project more reliable
  • This also makes it easier to know which CSS you can touch
  • It’s harder for classes to conflict with other classes
  • Which HTML tag you use is more or less independent from the CSS you use (provided you use a reset at the beginning of your stylesheet)
  • There is a performance improvement. Because CSS selectors are read from right to left, and BEM relies mostly on single classes (not SCSS nesting) it is faster
  • There are fewer specificity problems because you typically only write classes without too much nesting
  • Components are highly portable from project to project. In practice this means an improvement in code quality and development speed.

Of course, BEM has some disadvantages as well:

  • Class names can become a bit long and ugly (I don’t care because now they contain some “logic” which can be used towards our advantage e.g. linting)
  • The HTML can have a lot of classes which sometimes do very little (the HTML can start to look ugly as well)
  • Frameworks like Bootstrap are not BEM based so combining these with BEM can lead to inconsistency in class names, which might lead to confusion

For me, for small sites maintained by a few people or a single person, it’s unnecessary to use BEM, and I would rather use normalize.css and a set of easy to type class names.

For large software projects (the type of application CSS we usually write), BEM is the way to go. It costs a bit of effort in the beginning but saves a lot of time in the long run. Onwards!

Johan Ronsse

About the author

Johan Ronsse is an interface designer who is trying to find the balance between aesthetics and usability. He tweets as @wolfr_2.

Subscribe to our newsletter

Receive blog highlights and fresh insights into UX/UI and front-end development.

6 thoughts on “Learning to Love BEM”

  • No avatar
    Derryl

    6 May 2015 at 20:42

    I use a modified version of this syntax, which is arguably less readable than true BEM, because I abbreviate a module (block) name when selecting its sub-components (elements).

    .block-list { }
.bl--title { }
.bl--description { }
.bl--desc-info { }

    I like the brevity of my approach, but I recognize that all of my abbreviations are probably a weakness (especially on larger teams).

  • No avatar
    Xavier Bertels

    7 May 2015 at 12:26

    @Derryl I think that’s an interesting approach, although it probably makes things a bit less searchable, or it might introduce ambiguity in your namespace at some point:

    .block-list {}
.bl-description {}

.beautiful-links {}
.bl-description {}

    Not the best example, but on larger projects, this is definitely something that can happen. I think that is precisely where BEM’s verbosity really shines.

  • No avatar
    Nick Beukema

    12 May 2015 at 14:16

    @Derryl I also think using that abbreviated approach takes away from the ability to nest in LESS or SASS.

    .block-list{
  &__description{

  }
}

    I’m in the process of working on a project with BEM for the first time, and it’s definite strength is dealing with modules.

    Great post. It outlines the pros and cons very well.

  • No avatar
    Anenth

    13 May 2015 at 06:49

    “Frameworks like Bootstrap are not BEM based so combining these with BEM can lead to inconsistency in class names, which might lead to confusion”

    I don’t think it will lead to confusion, i think it will reduce confusion and decouple bootstrap style from custom style. For the custom components which are not provided in bootstrap can be written in BEM making it easy to differentiate between its coming from bootstrap or its our styles.

  • No avatar
    Yelena Jetpyspayeva

    19 May 2015 at 11:53

    Hi guys,

    thanks from the whole BEM team for the article, its simple and to the point! We would like to repost it on en.bem.info/articles with a link to you of course and all the credits, if you don’t mind?

    We also very much welcome you to join or community. Its huge in Russian language, if you check ru.bem.info/forum where posts and questions appear everyday, and we hope English language will grow one day too. We are very much open to help you and answer all your questions and simply get to know you better via en.bem.info/forum — forum powered by github login.

    Once again, thanks a lot!

    Yelena, BEM developer relations at Yandex

  • No avatar
    Pete Blatchford

    21 Jul 2022 at 18:20

    Lovely concise summary Johan, I’ve seen lots of articles on how to implement BEM but few detailing why it’s useful. I’ve circulated this to other front end devs in my team. I think you missed an extra hyphen in the example of a modifier in the third bullet point: There might be a modifier e.g. .`.my-element__sub-elelement–highlighted` (the 2 hyphens denote a modifier state).

Leave a comment

Your email address will not be published. Required fields are marked *