To BEM or not to BEM?

Please note: while I’ve worked as a front-end developer, my primary role has been design or design-related roles (researcher, product owner, teacher, analyst, and gloriously-but-briefly chief design officer) for over a decade. Over the past few months I’ve been updating my coding skills to incorporate new dev approaches and modern build tools. I’ve noticed any particular approach preference depends on the instructor: hence, surveys.

Below are the results of a survey on managing CSS, together with a brief history of web style development from my perspective, and why BEM is a preferable choice.

Survey results

A week ago I started several surveys on different sites about “To BEM or not to BEM,” asking developers for their preference on managing CSS. Did they like traditional cascading styles, or the popular BEM (block element modifier) approach? Or was there something else, something I didn’t know about? Below are the integrated results.

Spoiler: BEM clearly won.

While it looks like BEM is tied with “Either,” nobody voted for traditional, cascading style sheets. This could be interpreted as meaning that while developers are capable of doing whichever approach is requested of them, given a choice they [probably] prefer BEM. (Note: I didn’t get many responses — twelve — so take this interpretation with a grain of salt. Also, one of the respondents under “Either” actually chose “Something else,” but in a comment did not offer a third option, instead saying the choice between BEM or traditional cascading CSS depended on context. I took this to actually mean “Either,” but you can mentally move that vote to “Something else” if you like.)

Why BEM?

So why would developers prefer BEM? Cascading CSS styles, while inherent in the language, were the approach of choice in the past. Seeing too many styles attached to HTML elements was almost as bad as writing inline code. Designers and developers alike (at least the ones I worked with) felt that customer experience consistency and clean code alike were well served by using CSS as it was originally intended: cascading top-down into HTML elements, or according to IDs.

BEM, on the other hand, can fill elements with a variety of CSS classes. It’s not pretty, and to an outsider it looks like a monster to keep track of. Why would developers like this?

Times have changed

At the time of CSS’s creation, web development was young. Styling was actually being done using HTML modifiers — like < p align = “right” >, or the dreaded table modifiers (see below). (Tables were often used to force page layout, too. This was a dark, mostly non-semantic era.)

Over time, this changed. CSS appeared, and as people explored its many possibilities, a clean, semantic web code began to emerge. Search engines were a force for good in this evolution, rewarding semantic code with better rankings. As a result, developers associated clean HTML elements with good code. The only modifiers for elements should be stylesheet-driven CSS classes (preferably cascading) or IDs (which could be styled using CSS). On larger sites this could be a challenge, but techniques were adapted to help maintain style.

At both Nortel Networks and Texas Instruments, I was a small part of efforts to transform the entire site from static to dynamic. In addition to multiple content management tools, the greatest tool at TI was their style guide, which captured the variety of page layouts, design patterns, modules, etc., available to developers or designers. A couple of years later, the BBC launched the astonishing GVL (Global Visual Language) 2.0, a deliberate compilation of grids, design patterns, icons, colors, etc. They now call it GEL, Global Experience Language, and it’s well worth exploring and reading their articles.

Ever since, maintaining a living style guide (code + design + recommended use) has been valuable approach for me, not just for optimizing customer experience, but as an important support tool for developers. (I have yet to meet a developer who didn’t want to create a great experience, though I’ve met a few who didn’t think they had the time to do so.) And a major part of creating a successful style guide was (please note past tense) top-down, simplified CSS.

But this doesn’t tell us why BEM is desirable.

Build tools FTW!

In those early days of spotty CSS usage, developers didn’t have a lot to help them out. We were thrilled with an improved text editor. Versioning was an eternal challenge, so when Github appeared, there was much rejoicing. Application frameworks had been with us throughout, but Twitter Bootstrap, the first (I think) of the ready-to-go front-end frameworks revolutionized the speed with which a site could be built. Libraries like jQuery were amazing until frameworks like Angular stepped things up. But actually making it all happen was an art, practiced with differing levels of skill according to a developer’s familiarity with a given technology.

Enter front end build tools. These astonishing creatures (to me, at least) have revolutionized developing web apps. (Check out this great introductory article from freeCodeCamp.) Want to install Angular or React? NPM has you covered. Want to refresh your browser every time you save a file to see the results, or run a bunch of tests with one command? Turn to Node.js or Gulp.

This brings me, finally, to BEM. Gulp (and other tools, but I’m using Gulp) allows a developer to easily maintain many individual, targeted style sheets, automatically combining them into an integrated single sheet for a web app. Along the way, it makes it easy to create or track module-based CSS. For example, when managing the styling for a hero image and overlapping text, why bother cascading styles under a single div when it’s so much easier to just assign a class? Future developers can simply pick up the class and use it, finding it easily from either the actual module’s code, or by browsing the granular, ideally well-named style directories and sheets available to dev.

While visually this may look less clean, this doesn’t at all undermine the semantic meaning of the code. Nor does it make it harder to maintain the site, because of, you guessed it, modern front-end build tools! Even when you’re designing your own site, BEM (+ build tools) can make it easier to find your way when you decide to update your brand’s look and feel.

A cascading style approach may still work for smaller sites, or for simple sites. But unless I’m missing something crucial here (please, more experienced developers, tell me if I am!), it seems to me that BEM (+ build tools) offers significant advantages in speed, maintenance, and as a result, consistent experience for customers. I’ll be styling my sites using BEM in future, as well as enjoying the current wave of helpful build tools.

This article is a waypost on my coding journey; let me know what you liked and what I got wrong in the comments. Have a great day!

— Cross-posted from a LinkedIn article.