Why I Choose BEM Over CSS Modules (Most of the Time)

Every frontend architecture decision has tradeoffs. CSS architecture is no different. After years of working with both BEM and CSS Modules across different teams and codebases, I have developed a clear preference for BEM in most situations.

This is not a “BEM is better” argument. It is an explanation of how I think about this decision.

The Decision Framework

When choosing CSS architecture, I evaluate three things:

1. Team familiarity - What does the team already know?
2. Tooling constraints - What does the build system support?
3. Long-term maintenance - Who will work on this in 2 years?

Why BEM Usually Wins

Zero Tooling Required

BEM is just a naming convention. It works with any build system, any framework, any setup. You can adopt it today without changing anything about your infrastructure.

CSS Modules require build tooling. That tooling needs to be configured, maintained, and understood by everyone on the team. When something breaks, you are debugging your build system, not your styles.

Readable in DevTools

With BEM, what you write is what you see. .card__header--active in your code is .card__header--active in the browser.

With CSS Modules, you see .card_header_3x7Fk. Debugging becomes harder. Onboarding becomes harder. Communication between team members becomes harder (“which element? The one with the hash ending in Fk?”).

Explicit Dependencies

BEM forces you to think about component boundaries. When you name something .card__header, you are making a statement: this element belongs to the card component.

CSS Modules hide this relationship behind imports. The dependency is implicit in the file structure, not explicit in the code.

Lower Onboarding Friction

A new developer can understand BEM in 15 minutes. Block, Element, Modifier. That is it.

CSS Modules require understanding the build system, the import syntax, the scoping rules, and the debugging workflow. It is not hard, but it is not trivial either.

When I Choose CSS Modules Instead

BEM is not always the right choice.

When the team already uses them

Consistency beats preference. If the codebase already uses CSS Modules effectively, I am not going to introduce BEM just because I like it.

When naming collisions are a real problem

In very large codebases with many teams, BEM’s global namespace becomes a liability. CSS Modules’ automatic scoping solves a real problem at that scale.

When the framework expects it

Some frameworks (like certain Next.js setups) are built around CSS Modules. Fighting the framework is usually a losing battle.

The Tradeoff I Accept

BEM’s downside is verbosity. Class names get long: .navigation__menu-item--highlighted. Some developers hate this.

I have learned to see verbosity as a feature. Long names are explicit. Explicit code is maintainable code. The few extra characters are worth the clarity.

Applying This at MapVX

When I joined MapVX as Frontend Tech Lead, the codebase had a CSS problem. Different developers used different naming conventions. Specificity wars were common. Styles leaked across components.

I could have introduced CSS Modules. The Angular setup would have supported it. But I chose BEM instead.

Why? The team was not familiar with CSS Modules. The existing styles were global. And we needed to ship features, not spend weeks reconfiguring the build system.

The migration was incremental. New components used BEM. Old components were migrated opportunistically. Within three months, CSS conflicts had disappeared.

The Broader Point

This article is not really about BEM versus CSS Modules. It is about how to make architectural decisions.

The best choice depends on context. Team experience matters more than theoretical benefits. Incremental adoption beats big-bang rewrites. And the most important feature of any architecture is that the team can actually use it.