A colleague of mine is heavily pushing the BEM (Block Element Modifier) method for the CSS in a project he's helming, and I just cannot comprehend what makes it better than the LESS CSS we've been writing for years.
BEM is a CSS methodology. Others include OOCSS and SMACSS. These methodologies are used to write modular, extensible, reusable code that performs well at scale.
LESS is a CSS preprocessor. Others include Sass and Stylus. These preprocessors are used to convert their respective sources into expanded CSS.
BEM and LESS are not comparable as being "better" than one another, they are tools that serve different purposes. You wouldn't say that a screwdriver is better than a hammer, except when considering utility to solve a specific problem.
He claims "higher performance"...
Performance would need to be measured between a classical CSS style of:
and BEM style of:
but generally speaking, CSS selector performance is not a bottleneck, and does not need to be optimized.
BEM "performance" is usually with regard to a developer's performance writing code. If the BEM methodology is used consistently and correctly, it is easy for groups of developers to simultaneously author distinct modules without style collisions.
He claims "readability" and "re-use"...
I don't know that I would tell a new developer that BEM is more readable. I can say that it provides some well-defined guidelines as to the meaning and structure of classes.
Seeing a class like
Tells me that there is a
foo block that is in the
bar state, and contains a
I would absolutely say that BEM is more reusable than a classical model.
If two developers create blocks (
bar), and both of those blocks have headings, they can safely reuse their blocks in different contexts without worry of a naming collision.
That's because, in a classical context,
.foo .heading and
.bar .heading would conflict, and introduce a specificity conflict that would need to be resolved, possibly on a case-by-case basis.
In a BEM site, the classes would be
.bar__heading, which would never conflict.
He claims "nested CSS is an anti-pattern." What does "anti-pattern" even mean, and why is nested CSS bad?
An "anti-pattern" is a coding pattern that's easier for inexperienced developers to learn and use than a more appropriate alternative.
As far as why nested CSS is bad: Nesting increases a selector's specificity. The higher the specificity, the more effort it takes to override. Inexperienced developers often worry that their CSS might affect multiple pages, so they use selectors like:
#something .lorem .ipsum .dolor ul.sit li.amet a.more
When an experienced developer would worry that their CSS might not affect multiple pages, so they use selectors like:
He claims that "everyone is moving toward using BEM, so we should too."...
That is a bandwagon fallacy, so ignore that as a bad argument. Don't fall trap to the fallacy fallacy, because a bad argument in support of BEM isn't a reason to believe that BEM can't be good.
Could someone please explain in detail what makes BEM better than LESS?
I covered this before, BEM & LESS are not comparable. Apples and oranges, etc.
My colleague is completely failing to convince me, but I don't know if I have a choice but to follow.
I recommend taking a look at OOCSS, SMACSS, and BEM, and weighing the pros and cons of each methodology...as a team. I use BEM because I like its strictness in format, and don't mind the ugly selectors, but I can't tell you what's right for you or for your team. Don't let one outspoken individual run the show. If you're not comfortable with BEM, be aware that there are other alternatives that might be easier for your team to support. You may need to defend your position with your coworker, but long-term it will likely have a positive effect on the outcome of your projects.
I'd really rather be able to appreciate BEM, than to grudgingly accept it.
I wrote an answer on StackOverflow that describes how BEM works. The important thing to understand is that your ideal selectors should have a specificity of
0-0-1-0 so that they are easy to override and extend.
Choosing to use BEM doesn't mean you need to give up LESS! You can still use variables, you can still use @imports, and you can certainly continue to use nesting. The difference is you want the rendered output to become a single class, rather than a descendant chain.
Where you might have had
With BEM you can use:
Additionally, because BEM revolves around individual blocks, you can easily separate code into separate files.
widget.less would contain styles for the
.widget block, while
component.less would contain styles for the
.component block. This makes it much easier to find the source for any particular class, although you may still wish to be using source maps.