Defining a frontend architecture that implements modern best practices including component-based development, atomic organization, and the BEM css naming convention may take more forethought when initially starting up, but has consistently (across our projects) proven to actually speed up development as a project matures, and save both time and money when updates or bug fixes are required. It will also make any future frontend developer's experience with the codebase far more pleasant!
Because we follow component-based development principles, our projects get faster to work on over time. If you don't do things that way, projects inevitably get SLOWER to work on over time. And you're never sure if the change you're about to make is going to affect all of the places you want it to, nor if it's going to change the way some other element in an unrelated part of the site will look, when you didn't want that to change.
Most designers are practicing component based design already. For example, they create a card component, and then just copy and paste it to a new place in the design file, changing only the content. It only makes sense that we do the same. That way, when we have multiple things on the site that should visually appear the same - regardless of data source or actual content - they will always look the same. We write markup, styles, and javascript once and then implement it everywhere that makes sense.
Atomic organization is almost strictly a developer experience improvement. Basically, it organizes your components from smallest to largest. (Atoms, Molecules, Organisms, Templates, Pages) We've found that while this naming structure seems unnecessarily abstract upon first introduction, every other option we've seen is either too specific to make re-use possible (or logical) or uses words (like "Blocks", "Modules", or "Chunks") that have too many possible meanings based on any given person's background that they mean different things to different people. The scientific nomenclature is abstract enough that it evokes the fewest pre-conceived meanings, while also accurately describing the relationship between components.
BEM is one of a handful of CSS conventions that serve the same purpose: "Componentize the CSS so that it doesn't cascade somewhere you don't want it to."
We've found ourselves (relatively) recently in the frontend world deciding that since component-based design and development has such a huge positive impact on the speed at which we can write - and the resilience of - our code that we often don't want the "cascade" that is inherent in CSS (cascading style sheets). So, we've had to find ways to ensure that the CSS we write is specific to the component it belongs to. In the javascript world, there is true isolation through styled components, CSS in js, etc. For traditional html/CSS/js websites though, that isn't possible, so we use a class naming convention to achieve a similar result.
At Four Kitchens, we've standardized on BEM because it gives us the flexibility, and when needed, the verbosity, to write our styles in a self-documented way that makes sense to us, and hopefully, our future selves as well as other developers. For example, the class .event-card__heading is pretty clear that it's styles will affect the heading of the event card... and have nothing to do with the "news card" which is a completely different component with different markup and styles.
Hey Brian, I love this!