BEM stands for Block, Element, Modifier. It is a CSS naming methodology developed at Yandex around 2007, and in April 2012 an introduction to it ran on this site as part of a series covering the new front-end tools of the moment. Here is what happened next: almost everything else in that series died. The prefixers, the grid generators, the clever plugins. The naming convention is the thing that survived. Fourteen years later I am republishing this URL with a different argument than the original carried, because BEM turned out to be less about CSS than I understood at the time. It is a lesson about what makes conventions outlive tools, and it earned its place at this address.
What is BEM?
BEM stands for Block, Element, Modifier. A block is a standalone component: a card, a nav, a form. An element is a part that only makes sense inside its block: the card's title, the nav's link. A modifier changes a state or variant: the card, featured; the button, disabled. The names encode the structure.
In CSS it looks blunt: .card, .card__title, .card--featured. Nobody has ever called it pretty.
The official BEM introduction is still live and still says it plainly: standalone entities, their parts, and their flags. That is the whole system.
Why did BEM outlast the tools of its era?
Because it was a convention, not a dependency. The 2012 series this URL belonged to covered a prefix polyfill, a responsive framework, a drafts library, a grid generator. Real tools, genuinely useful, all requiring installation and faith in a maintainer. All gone.
BEM required only agreement.
A convention costs nothing to adopt, nothing to leave, and it keeps working when the build system changes underneath it. It travels in the heads of the people who use it. You cannot deprecate an idea that lives in naming.
There is a pattern here I keep meeting in product work too: the durable part of any system is rarely the machinery. It is the shared understanding the machinery was built to enforce.
Is BEM still relevant in 2026?
The syntax matters less now; the thinking still matters. Scoped styles and component frameworks do mechanically what BEM did by discipline: they guarantee that a component's styles belong to it. In that world, writing card__title by hand is solving a solved problem.
But the core idea was never underscores. It was making the relationships between parts explicit, in names a stranger can read. That idea is alive everywhere: design tokens, component APIs, file conventions. And plenty of the web still has no build step at all. CMS themes, static sites, inherited codebases. There, BEM remains excellent, unchanged, and free.
I wrote recently about emotionally intelligent design, and this is the same principle one layer down. Code has a human on the other side too. The next developer is a user.
Should you use BEM today?
It depends, but the honest answer has a shape. Greenfield component stack: adopt the discipline, skip the syntax; your tooling already enforces the boundaries. No-build site, CMS theme, long-lived codebase strangers will inherit: BEM is still one of the best answers available. Zero tooling. Total portability. CSS a newcomer can navigate on day one.
The 2012 version of this page introduced a new methodology. The 2026 version can say what the original couldn't know.
Tools are bets on a maintainer. Conventions are bets on people agreeing. Fourteen years later, the second bet paid.