HTML & CSS

BEM and SMACSS: Advice From Developers Who’ve Been There

Patrick Catanzariti
Share

CSS methodologies can be mind bogglingly confusing and tough to decide upon. Let’s consider two of the most well known options: BEM and SMACSS.

Should you choose one of these for your next project? What are they best suited for? What might go wrong? If you’re already working with one – are you using it as intended? To the fullest potential? How do you know if you’re doing it right? I thought I’d be nice to ask people who’ve already been through those questions in their own projects and learn from their experiences.

I asked developers who’ve worked with BEM and/or SMACSS for their success stories, horror stories, advice, and words of caution. I gave some developers a whole list of questions and others just free-formed their thoughts to me. I’ve compiled the results into what I hope will be valuable reading for those considering optimizing their CSS.

For those new to BEM and SMACSS, I’ll start by giving a very high-level overview of what BEM and SMACSS are.

What is BEM?

BEM stands for Block Element Modifier and originated at Yandex. It provides a rather strict way to arrange your CSS classes into independent modules. There are a few variations on the idea but the most common one looks like this:

.block {}
.block__element {}
.block--modifier {}
.block__element--modifier {}

A Block represents an object in your website. For example:

  • a person
  • a login form
  • a menu
  • a search form

An Element is a component within the block that performs a particular function. It should only make sense in the context of its block. For example:

  • a hand
  • a login button
  • a menu item
  • a search input field

A Modifier is how we represent the variations of a block. For example:

  • a tall/short person
  • a condensed login form (e.g. we’re hiding the labels in one version)
  • a menu modified to look differently for a footer or sitemap
  • a search input field with a particular button style

In the example of our menu, the class names could look like this:

.menu {}
.menu__item {}
.menu__item--featured {}
.menu--footer {}

There are other architectural principles and tools for BEM on the bem.info website, however, when developers discuss BEM, they’re often focused mainly on the naming convention above and that is true of the majority of the discussion below.

What is SMACSS?

SMACSS is a CSS framework by Jonathan Snook. On the SMACSS website, he says it is more like a “style guide” than a rigid CSS framework. It focuses on five categories for its rules:

Base is used for defaults like html, body, a, a:hover. This includes your CSS resets and would often be in its own base CSS file or at the start of your main CSS.

Layout divides a page into sections with elements like header, footer, and article. Often developers show layout elements by prefixing the class with l-.

Module is a reusable, modular element in the design. The SMACSS documentation sees modules as the majority of your elements and thus doesn’t require that you prefix them but you could do so if you choose.

State is used for the variations possible for each element (e.g. active, inactive, expanded, hidden). These are prefixed with is-, e.g. is-active, is-inactive, is-expanded, is-hidden or are via pseudo-classes such as :hover and :focus or media queries.

Theme is similar to state but defines how modules and layouts will look. It is more applicable for larger sites with shared elements that look different throughout. You would add theme variations on a per page or per section basis.

Child elements in SMACSS (like what an “element” is to a “block” in BEM) have the parent item prefixed with a dash. e.g. menu and menu-item.

SMACSS states that it’s all up to developer preference and isn’t as prescriptive as BEM. SMACSS just provides basic guidelines. Use your own naming conventions for each of the categories and arrange them in your preferred way, as long as you document your approach so that other developers can follow along.

Guidance from those who’ve used BEM

It is applicable to all projects, big and small

Hamish Taplin, a front-end developer from Cardiff, UK, believes BEM is suitable for projects big and small and it offers plenty of advantages:

“BEM is touted as being for large projects but I don’t believe that at all. If you like writing code that is clean, maintainable, and not battling with specificity problems then BEM is for you. Some say that the HTML it produces is ugly or redundant but I think it’s beautiful. I can read some HTML and see exactly what is going on and how elements are related to each other. It’s great.”

It avoids nesting

Alec Raeside, a front-end developer from Sydney, Australia has found BEM to be a good way to avoid too much nesting of selectors:

“BEM is a good way to build UI. The descriptive, sometimes long, class names are good for understanding straight away where this class/selector sits within your UI architecture. It also means you rarely need to nest selectors, a common downfall with Sass codebases. Usually when I’m nesting with BEM is when I want to target an element via HTML tag name, or to win a specificity battle when components styling overlaps.”

It helps you rediscover the power of classes

Hamish Taplin sung the praises of BEM and object-oriented principles. He raises interesting thoughts on the concept of “semantic” markup:

“The advantages of BEM were apparent immediately. Prior to adopting BEM and OOCSS principles I had been an advocate of what is (incorrectly) known as “semantic” markup. I think a lot of developers (me included) have largely misunderstood what this actually means and had been neglecting the power of classes under the guise of them not being “semantic” enough. Search engines and screen-readers don’t care about the classes you use or some extra divs used for a grid. Twitter engineer Nicholas Gallagher totally nailed this with his blog post “About HTML semantics and front-end architecture” when he says: ‘…not all semantics need to be content-derived. Class names cannot be “unsemantic”. Whatever names are being used: they have meaning, they have purpose. Class name semantics can be different to those of HTML elements.’”

Makes working on larger sites easier

One huge strength of BEM that a lot of the developers mention is its ability to handle developing and implementing large and modular projects in a cleaner fashion. While BEM is not only for large sites, it does appear to have great advantages in this space. Hamish discussed his experience and even has a whole blog post about it:

“I dabbled on a few small projects and got to grips with it — it was quite hard at first as it was contrary to the way I had been working for years but the benefits were becoming obvious. Then, we started on a project that was quite big and very modular in nature — My Health Skills. This was the first Bluegg project I had worked on where I was working with another developer (Paul Goodfield, who had also been using BEM) — I did the front-end and Paul the backend. The benefits were immediately obvious, Paul could understand exactly what my markup was doing and write his Laravel templates around it. If he needed to fill in some gaps then the predictable nature of BEM meant he could write the HTML just as I would have and the whole process was made much smoother. I wrote about this in a blog post “Building My Health Skills”.”

Alec Raeside also found benefits to large projects through the modular nature of BEM naming. He says:

“BEM is well suited to large projects. CSS is complex and large projects can fall down where unspecific selectors can cause unintended consequences elsewhere. For example, targeting all <ul>s under a selector like .container ul {} may work when that code was written, but once many other components are nested in a .container component, the ul styling may not be appropriate. With encapsulation and specificity at the heart of the BEM methodology, it can help prevent naming clashes between components and unspecific selectors from accidentally styling some of the page.

The BEM methodology encapsulates your code for reuse

Harry Roberts, a Consultant Front-end Architect, designer and developer from the UK who has contributed a huge amount to the ideas in the area of BEM and authoring clean CSS, pointed out that the BEM methodology makes it easier to reuse components across websites through its encapsulation:

“The BEM methodology is ideally suited to projects where your components might need to be moved from one codebase to another; they need to be fully encapsulated so that you can just move one chunk of HTML, CSS, JS across to another project, and you don’t have to take any dependencies with you. Let’s imagine you work for a company that has five different sites, and they all need the same carousel on the homepage. You’d write that carousel in the BEM methodology so that you can pick it up in one piece and move it around.”

Works well with frameworks with a component-based focus

Josh Hunt, a front-end developer from Sydney, has found it plays nicely with other frameworks with a similar component focus:

“BEM does really well for sites that have lots of self-contained widgets or components, like web apps. Frameworks that promote HTML components (Angular, React, Polymer/Web Components) also make it a lot easier to apply BEM methodologies.”

Quick way to deliver prototypes

Bob Donderwinkel, a front-end developer from Rotterdam, the Netherlands, gave a great presentation on “The benefits of BEM CSS”. He points out the biggest advantage he found with working with BEM:

“I have been dabbling with BEM for half a year now and used it in two projects: a new scrolling gallery page for www.viewbook.com and reworking an old Flash site to an HTML version. The designs for these projects were well defined and I would say the biggest win using BEM was delivering a prototype fast. And that’s mainly because “deciphering” your design in Blocks, Elements, and Modifiers gives you a nice head start to code up some CSS.”

Makes you think twice

Josh Hunt finds that the naming convention helps you think twice before making things too complex:

“I’ve found due to the fact that it is a bit ugly, it forces you to think twice when going to write really long class names.”

Make sure you plan!

Hamish Taplin also provided these words of advice for those starting a new project:

“Have a degree of planning when you start a project. I tend to go through the mockups and look for patterns I can abstract into BEM modules. This can be hard at first but you get better at it to the point where you start to re-use old patterns. Re-using code is the nirvana of development and something your boss will thank you for when production costs go down because you’re more efficient!”

Don’t get too strict with it

Josh warns about getting too restrictive with your projects when aiming to use BEM:

“Don’t feel restricted by BEM or feel like you’re being forced to follow some weird pattern. I’m drawn to these two tweets by Harry Roberts:

Josh explains, “BEM shouldn’t be the goal of a project, it should be something you keep in mind as you’re developing and apply where useful. Don’t get too carried away trying to stick to some theoretical ‘standard’. Helper classes (like .pull-right or .text-center) are totally cool to co-exist with BEM. Where you might have had class="story--centered", class="story text-center" will do just as well (perhaps even better).

If you’ve been hesitating, just jump in and give it a go

Hamish didn’t take the leap into BEM straight away. It took a bit of time, an influential presentation, and changing jobs, to get him to reassess and put BEM to work on rethinking his classes. But he’s glad he did.

“I’d seen BEM mentioned a few times and thought it looked interesting but still carried on as I was, attempting to minimise the amount of markup and classes I was writing, using Sass @extend to work around the problems this causes. One day I watched Harry Roberts’ video “Breaking Good Habits” and was blown away. This guy was spot on — what problems were we actually solving by doing this?”

Hamish goes on to say, “I was moving jobs at the time, starting at my current job at Bluegg and saw it as a clean break for trying BEM out.”

I asked Harry, that same developer who blew Hamish away with his talk on “Breaking Good Habits” and who inspired Josh with his tweets, if he had any particular success stories to share. His words echoed the “give it a go” mentality:

“Every project I’ve worked on has benefited from the BEM naming convention. It’s not an instantly life changing thing, so it’s hard to cite success stories per se: usually it is just one of many parts that come together to create a much better whole. Like a steering wheel itself isn’t very profound, but it’s a vital part of a car; BEM naming is one thing that makes an entire project a lot better.

“The closest I have to a success story, perhaps, is the time I introduced BEM naming to a client of mine. He’d avoided BEM naming for a long, long time, citing the oft-used “But it’s just so ugly!” I convinced him to at least give it a try on a project for just half a day, and see what he thought then. He loved it. After only a few hours he was putting underscores in here, and double-hyphens in here. It’s always great to see people have that light bulb moment.”

Harry also put the following question out there for those who are uncertain:

“If you’re unsure about BEM, answer this question: What is there not to like about a strict, transparent, and meaningful way of naming things? Honestly, there are no downsides to using BEM naming.”

I’ll leave the final words on this to Hamish Taplin who said:

“Just try it. BEM is about solving problems so see if it does that for you. I’ve seen it dismissed on many a forum or discussion by people who have never tried it and wish to keep their markup “semantic”. I was the same until I took the plunge and it completely changed my entire outlook on how I should write HTML and CSS. You have to be prepared to adapt and admit when you are wrong if you want to build great products.”

Guidance from those who’ve used SMACSS

Ease of demonstration and handover

Chris Wright, a Sydney-based developer, is a big fan of SMACSS and offered his advice. Chris’ main praise of SMACSS is the ease of use of its categorization features:

“Once I started leveraging the reason why SMACSS was so powerful, the categorization features, I found it to be a really readable and teachable methodology compared with the other popular CSS methodologies.”

“I’ve been using it as a contractor because it’s so much easier to demonstrate to people – here’s my stylesheet: classes with an l- in front of it concern layout, things with m- in front of it are modules, and so on. While I still have to handover and explain, the amount I have to explain and document has been reduced so it’s saved me more time outside of the work as well. As of last year, I’ve started using it on every project I can.”

Good for newcomers to a CSS methodology

Chris particularly found he had trouble getting others to work with early versions of BEM and OOCSS but SMACSS was easier to explain:

“I’ve found that it’s far easier to explain to a developer that’s never encountered a CSS methodology before – what the value of that methodology is and how to use it.

“I tried for a while with BEM but always found people would get confused. With OOCSS I found that people’s naming conventions were often all over the place but they generally got it. SMACSS offers categorisation that helps you see straight away what the purpose of a class is.”

Ease of reading

Chris also said he found early versions of BEM to be a bit verbose but has seen it developing over time, he prefers SMACSS here.

“Also from a reading point of view, all those underscores and dashes and crazy long classes in BEM tended to turn me away from it – I’ve seen some more adapted versions like what Harry Roberts has done as a pretty huge improvement on the methodology, but I still don’t feel like it’s for me.

Scalable for all projects

Chris also points out that SMACSS doesn’t need to be completely followed in the same way on larger sites compared to smaller ones, which allows for flexibility and applicability in all projects:

“I think it’s safe to say varied forms of SMACSS can be suitable for all projects. As Snook states in his book – on a smaller project you probably wouldn’t use things like theme as a category (t-), but being able to differentiate a layout class from a module class from a glance is pretty valuable.”

You can use SMACSS and BEM

Hamish Taplin actually takes a hybrid approach, using some SMACSS concepts within his BEM. I found quite a few developers have found a sweet spot between the two, so it might not be a matter of choosing one over the other:

“I do use some SMACSS concepts and I don’t see them as mutually exclusive. I organise my Sass into “base”, “layout” and “modules” which are broadly SMACSS conventions. I’m also a big fan of using ‘state’-based classes in my JavaScript. For example, a module that can be visible or hidden might have is-visible or is-hidden classes controlled by JavaScript. I find this helps distinguish what is controlled by JavaScript rather than using BEM-style modifiers. I wouldn’t be against that though.”

Bob Donderwinkel agreed that a mix of both BEM and SMACSS is possible in most situations:

“I would say using one does not exclude the other, although there is some overlap with BEM if you consider the module and state rules from SMACSS. But besides these you can mix and match both up as needed.”

Harry Roberts recommends choosing the best bits from everywhere and uses his own methodology that he calls “ITCSS” with a combination of BEM, SMACSS, and OOCSS.

“I actually use my own — as yet unpublished — ITCSS methodology alongside smatterings of OOCSS, BEM, and SMACSS. It’s hugely important to pick bits from everywhere, rather than blindly follow one methodology right to the bitter end. I always use BEM naming, and would use the BEM methodology on projects where I need fully encapsulated components that need sharing across multiple codebases. I would write these components using OOCSS, and then I would wrap these components up into an ITCSS architecture.

“It doesn’t start and stop with BEM and SMACSS. ITCSS is designed to encompass entire projects; OOCSS is a great little methodology that is everything-compatible; SOLID principles can be used to write better quality CSS.”

If you’re keen to find out a bit more on ITCSS, Harry has a a video available for you to watch. For more info on SOLID CSS principles, Harry also offered these two articles:

If you haven’t done so, read the SMACSS guide

Harry Roberts strongly recommends reading the SMACSS guide:

“Just read up on it. SMACSS is one of the best bits of front-end reading that’s come out in the last few years, and it’s very difficult to disagree with the logic it puts forward.”

Horror stories on BEM and SMACSS

I tried to get some horror stories and words of warning from our developers – lessons we could learn from their missteps while they were in the learning process. Here are their thoughts.

Alec Raeside on BEM

“It is quite a learning curve, it isn’t conceptually too difficult to understand, but it takes a while to change your habits of writing normal CSS/Sass. It’s very easy to NOT think in a purely component based way. I’ve been writing BEM all year and still feel like I’m learning and upgrading the way I write it. Sometimes you have to write a bit more CSS with BEM compared to non-BEM CSS to achieve something which is annoying, but it’s best to have consistency.

“BEM in itself isn’t enough to build UI the best way possible, we combine BEM, mobile first CSS, appropriate use of Sass and strict coding standards. We haven’t got it perfect but it’s getting better. We have also recently started using scss-lint to help enforce our coding standards and to a lesser extent our BEM usage.”

Chris Wright on SMACSS

“Most of my horror stories aren’t really horror stories but places of pain. I have been encountering agencies that are really Bootstrap framework heavy who want to continue with more of an OOCSS approach, which is fine (OOCSS is pretty good too) – but trying to convince someone that uses an approach that comes with their particular framework to slightly adjust their methodology for their projects that don’t use the framework is a fairly futile argument to be having. So I have had to leave it in those cases. SMACSS’ biggest weakness I’d say is actually that it’s less widely adopted than BEM or OOCSS – it seems like fewer people have heard of it.

“My own personal stories with implementing it have been not really adhering to the point of the methodology. It’s very easy to fall in to the trap of “module all the things”, and forget that the categories that were suggested were exactly that, a suggestion. The hardest part is understanding what qualifies in each category. Is a globally used primary button a module called .m-btn-primary? Or is the thing it lives in the module? It can be confusing when you first start using methodologies, and in the case of SMACSS where you’re clearly defining things like layout, modules, and themes; I’ve run into a few situations where I had to stop and think where something belonged, but that’s also been a positive for me, and the point is we want more organised classes that people can read and understand easily.”

Josh Hunt on BEM

“First time using BEM will more often than not be a nightmare. My first time I was creating .classes__about__five__levels__deep. BEM is not supposed to be a one-to-one mapping of DOM structure to class names.

“What I’ve found difficult to apply BEM to is when you need extra elements purely for styling, like .wrapper or .inner. It’s not really right to have an .article__inner (inner isnt an element of an article). Sometimes you can be creative with the words you choose (div.article__media img.article__img), but other times it’s perfectly fine to “break” BEM and go .article-wrapper or .article-inner.

Hamish Taplin on BEM

“I think the biggest challenge with BEM is inherent in abstraction — it can be difficult to get your head around sometimes. It requires a degree of planning to spot the patterns that can be abstracted and you sometimes end up having to refactor when you don’t spot things the first time. This is common in development though and planning and experience can help a lot.

“Another sticking point is that it requires total control over markup—something that can be difficult if you’re working in an environment (such as .NET) where this isn’t always possible.”

Harry Roberts on BEM

“Because BEM naming is just a GoodIdea™, it’s very rare that you’ll hear any horror stories. The closest I can think of took place with a really great client of mine back at the beginning of the year. They were a really diligent team who’d done a lot of research and reading into better CSS architecture, and they got me in for a week of training to try and iron out any rough spots. One of the roughest spots was with their implementation of BEM naming. Unfortunately, they’d read an article (which, in the interests of not perpetuating, I will not link to here) that gave some really, really bad advice on BEM naming. Fundamentally flawed information that was just plain wrong. The client followed this advice to the letter and it got them into some real troubles. Things were more tangled and interconnected than ever before—something that BEM naming is meant to solve! That is, however, the only incident I am aware of.”

Bob Donderwinkel on BEM

“Well I wouldn’t call it a horror story exactly ;) But I made a little BEM scaffolding tool called kaBEM. The mistake I made there was using BEM CSS class names with multiple elements (like block__element__element). Mainly because that helped in generating a nicely nested folder structure based on those CSS class names. In essence I was capturing HTML structure in CSS class names, but that actually makes BEM a little bit more rigid, which is not needed.

“Another little gotcha was that nesting BEM CSS selectors like you can do with Sass or LESS actually adds CSS specificity where it is not needed. BEM works best as single class names, so that’s perhaps something to keep in mind.”

Conclusion

After going through everyone’s responses and ideas, it was clear that the best approach seemed to be a hybrid. Read up on everything, give both BEM and SMACSS a go with an open mind and see whether your CSS and workflow improve. You don’t need to choose one methodology; combine the concepts of a few methodologies into one that works for you and your team. If you need help, there are plenty of developers out there willing to share some thoughts and advice.

Credits

A very big thank you to the following developers who were kind enough to give up their time to answer my questions and share their thoughts and experiences: