Time to Stop Using BEM

Time to Stop Using BEM

CSS architecture was much different 14 years ago. Having all the styles under a single global namespace was common, and in large codebases, naming collisions and overrides were unavoidable.

This is why back in 2010 Yandex introduced BEM. A structured convention for namespacing styles.

It works by identifying independent entities and treating them as reusable Blocks. Every part inside the block is called Element and it is named using the convention {block-name}__{element-name} Additionally, different states are represented with modifiers which follow the pattern {block-name}--{modifier-name}

For example:

<div class="button button--primary">
  <span class="button\_\_icon">♥</span>
  <span class="button\_\_text">Add to favorites</span>
</div>

• Block (button): The main component.
• Elements (button__icon, button__text): Parts of the block, related to it but not related to other blocks.
• Modifier (button--primary): A block variation, such as a primary or secondary style.

It made so much sense that every large codebase rapidly adopted it. Soon, it became the standard for managing CSS in complex projects.

However, as projects grew some challenges began to surface:

• **Verbose and Long Class Names
  **BEM’s strict naming convention often results in long, repetitive class names, especially for deeply nested elements or components with multiple modifiers. The following example, while it improves clarity, it increases the size of both the HTML and CSS, making the code harder to read and maintain.

<div class="menu\_\_item menu\_\_item--active menu\_\_item--with-icon">
  <span class="menu\_\_item\_\_icon"></span>
  <span class="menu\_\_item\_\_text">Home</span>
</div>

• **Hard to Refactor
  **BEM tightly couples class names to the structure of our HTML. When design changes, we may need to rewrite a large number of class names, which can be tedious and error-prone.
• **Global Namespace Issues
  **Despite its namespacing strategy, BEM still operates in a global CSS namespace. This means that unrelated styles can still unintentionally overlap if naming conventions aren’t strictly followed.
• **Manual Work
  **BEM relies on our effort to manually enforce it. Inconsistent usage can lead to confusion, especially in large teams or codebases.

Despite these challenges, BEM became the de facto standard in many codebases and is still widely used today.

But times have changed.

Modern front-end frameworks are now built around component-based architecture, where modularization and encapsulation are fundamental concepts. Styles can be scoped automatically to individual components during the build time. This means that namespacing, one of the core strengths of BEM, is no longer something we need to handle manually.

Let’s see a few framework-specific examples:

• In React the most common tools are CSS Modules or CSS-in-JS libraries such as Styled Components and Emotion. They automatically scope styles to individual components, preventing conflicts and removing the need for manual namespacing.
• Vue supports [**scoped styles**](https://vuejs.org/guide/scaling-up/scoped-styles.html) natively. When you define styles inside a <style scoped> tag in a Single File Component, the framework automatically scopes those styles to that component using unique data attributes, ensuring no leaks across components.
• Svelte takes a similar approach to Vue. By default, styles written in a Svelte component are scoped only to that component. Svelte achieves this through compile-time processing, adding unique classes under the hood to prevent conflicts.
• Angular uses ViewEncapsulation to manage styles. By default, it uses Shadow DOM or emulated encapsulation to scope styles to specific components, keeping them isolated from the rest of the application.

While BEM served its purpose and brought a much-needed structure to CSS at the time, the ecosystem we have today addresses the same challenges in smarter, more efficient ways. For now, moving away from it is a step forward, leaving behind outdated practices in favour of modern tooling and encapsulation.