Skip to content

Instantly share code, notes, and snippets.

@ModulesUnraveled
Last active June 1, 2023 10:57
Show Gist options
  • Save ModulesUnraveled/d6b59295d6e8172f3ab9bbad26afb9e2 to your computer and use it in GitHub Desktop.
Save ModulesUnraveled/d6b59295d6e8172f3ab9bbad26afb9e2 to your computer and use it in GitHub Desktop.
Frontend Methodology

Summary:

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!

Component Based Development

DRY (Don't Repeat Yourself). Write code once, and re-implement it - instead of rewriting it

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

Component Organization Structure

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

CSS Naming Convention

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.

@jmmcduffie
Copy link

Hey Brian, I love this!

  • I think your summary is spot-on, and we've found the same benefits in our work that you've articulated.
  • Great job explaining the key risk of not using component-based development, and I love the connection you drew between how the design team works and a component-based approach for coding.
  • I think the context is helpful there for why BEM is needed and that it strengthens your argument.
  • Overall, I think you've done a good job making your case here. It would be great to see some additional notes about architecture such as the role of non-component CSS (is there any? what kinds?), best practices for authoring component-oriented CSS, or notes about testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment