Thanks to BEM’s naming conventions, what used to be a big ball of HTML became a suite of nested components. However, for many of us the component abstraction didn’t go further than the style sheet.

Our single page apps could quickly devolve into a collection of massive controllers with overly bloated templates, combining multiple blocks into a larger, combined view.

Remember the gist of this (admittedly contrived) markup, we’ll revisit it later.

<div class="my-page">

<header class="header">

<h1 class="heading header__heading">...</h1>

</header>

<article class="post">

<header class="post__header">

<h1 class="heading post__header__heading">Hello World</h1>

</header>

<section class="post__content">...</section>

</article>

<footer class="footer">...</footer>

</div>

This is the environment in which the verbosity of BEM’s naming convention could evoke repulsion from many developers, but this reaction was arguably a sign that BEM was merely being applied at a surface level. Without JavaScript, this technique could only take us so far.

The Yandex team also developed a matching JavaScript implementation for BEM, but it used a custom template format that isn’t widely used — certainly not to the degree that BEM is used for CSS.

As we move into a world of component-based UI libraries like React, Ember and Angular — not to mention Web Components themselves— the thought process that many of us honed with BEM can now help us write better JavaScript.

That is, of course, assuming that we properly leverage the tools these frameworks provide to help us break our applications down into smaller, re-usable pieces. Many applications — particularly those using frameworks with string-based templates like Angular and Knockout — only leverage components for lower level widgets, nesting them inside more traditional pages with many concerns jostling for your attention.

Fighting to build a truly component-based architecture requires careful consideration. We need to reframe the way we think about our front-end architectures — it needs to be components all the way down, consistently across different asset types, and not simply at the edges of our application.