BEM is the type of nonsense the OOCSS fanboys cream their panties over, and to me it only contributes to bad practices of not leveraging selectors properly. Classes and ID's should be a last resort AFTER you've used up your semantic tags, not your go-to to slop onto everything.

You can TELL the folks who encourage the use of BEM are -- as I oft point out -- unqualified to write HTML or CSS; as evidenced by such gems of ignorance and ineptitude (there are those two words again) as:

<div class="block block--size-big block--shadow-yes">

Classes saying what things look like and not what they ARE? Classes that are redundant to inheriting off the parent? That's both pointless code bloat AND presentational use of classes, a double /FAIL/ at web development.

Hardly a shock that 'getbem" website is itself a bloated wreck using two to three times the HTML necessary to do the flipping job!

Overall it reeks as the same garbage some folks advocate of slopping classes onto everything to avoid using selectors entirely -- one of the DUMBEST pieces of advice and based entirely on a LIE about how selectors slow down the render time.

If your site is well coded, render time should be bupkis, at least compared to handshaking and transfer time. Slopping out two dozen separate stylesheets and two to ten times the markup is going to effect your page loading time a hell of a lot more than "oh noes, you used child selectors four deep!".

Much like the idiocy that are front-end frameworks, OOCSS, SCSS, and all the other hot and trendy media darlings, their claims are 100% bunko, the people creating them seem to have failed to grasp the most basic concepts of HTML and CSS, and in general they're a blight upon web development as a whole. AT BEST they are crutches for the inept, at worst... I lack the words in polite company.

That and to be frank, I do not find it aids in clarity or legibility one iota -- quite the opposite in fact.

I personally think BEM is overkill, and leads to bloated HTML and CSS. I think the way class names are used doesn't make the best use of CSS features (which can match parts of attribute values, if a value starts with, contains anywhere, contains in a space-separated list, or ends with a value).

Also keep in mind that BEM came around in 2013 (half a decade ago) mostly to deal with the way HTML was written for pre-flexbox, pre-grid layouts. There are better, stronger, more lightweight ways we can build HTML now, which means to a great extent, the problem BEM aims to solve doesn't need to exist as much anymore.

But, I won't say not to use it, or that it's bad. It works, so just take the parts of it that still make sense to the technology, and use the parts that actually give you a boost when you're naming things or writing stylesheets. There's no need to adhere to it strictly or fully, just use it so far as it helps you and no further :D

I've actively used BEM for a few years now, and it helped me a lot. I think, BEM is a great tool to write lean CSS. However, it might as well be one of the hardest to learn and use correctly. That's why some people are against its usage and others shy away from it. To be honest, I still wouldn't say that I am very good at writing BEM myself One might say that that's one of its flaws: it's hard to name a block and not fall back to creating scopes inside the name.

However, the basic usage of BEM yields great benefits. By looking at a class name, you instantly can deduce, which elements should be affected and where they are probably located, if you know the general site layout - even after years, or on a foreign codebase. You do not need long names to achieve that, either. All you have to do is sit back a bit, move your mind a step away, and think about where the element is located logically (not in your HTML structure, which is what you are probably thinking about at that moment).

Another positive aspect of BEM is that it yields a flat hierarchy. There is not sub-element selector. You can easily leverage and mix it with many other CSS tools. For example you can re-order your classes in an inverse specificity (ITCSS: Inverse Triangle CSS), which means that more specific selectors automatically overwrite inheritance from higher selectors in your HTML structure, which leads to you not having to worry about what will change on the rest of the page (by CSS inheritance), and how to make a style even more important after you already used !important.

Of course, BEM can be mixed with SCSS. You can use SCSS to split up your huge file, you can define your basic design colors, you can create mixins for your transitions and a lot more. Just don't do scoping.

BEM can also be extended by applying namespacing, which adds additional information, for example if the class only affects a single element, or might affect 0..n elements, or should not be touched by anyone, even though it has no selector in CSS, because it is used in a script. Namespacing makes it easy to deduce how changes to a class might affect the whole page.

I highly recommend reading about BEMIT and ITCSS. That's where I learned from, and that's what I made very positive experiences with. The one behind these articles and methods, Harry Roberts, also hosted an AMA here on Hashnode some time ago, you should check it out, too ;)

I thought about using BEM and tried to use it, but I have quietly gone away from it again. As you point out the naming conventions are often very and it leads to a few overhead problems:

• Hard to remember the correct path name and no IDEs will help you
• If the structure changes you might have to refactor a lot of CSS
• Longer class names means more bytes, not much, but it's a margin

Since I'm uing SCSS it makes more sense to try to adapt a namespace OOP pattern to my CSS. Simply if I have a component testimonials that would be:

.testimonials {
  > .testimonial {
    > .title {
      // CSS
    }
  }
}

If you are consistent doing this and not making an independent .title then this approach works very well in my opinion.

If you want to have a generic class, you can always use BEM here:

.utilitiy__ {
    &title {
      // CSS
    }
}

But you could also simply call it .title as it would still not be inherited from a .testimonial

BEM is a waste of time, imo. It takes longer to learn what NOT to do when you "BEM the rules" than it would just to do it in a dev-friendly, DRY manner. It seems to encourage folks to ignore the "Cascading" in CSS way too often - which is like trying to use nothing but an open flame, and your hands, to cook an egg.

Also, if you're having a hard time evaluating any type of code, you may need to blame the person who wrote it.