Jono Herrington

Build A Strong Sass Architecture: Part 1

I am not going to lie to you, there are not many things that get me as excited as Sass architecture does. You can me call a geek. You can call me a nerd. You can call me a weirdo. I do not care. I love it.

The reason I am so passionate about Sass architecture is because I believe that it can make or break how comprehensive your code really is. Let’s face it, CSS is hard. The main reason for that is because one of the most difficult things in developing, is naming things. In CSS you name almost everything! If you layer Sass on top of that, with partials broken up into weird and incomprehensible ways, inside strange folder names, you may as well just throw in the towel.

But to start off, I have a confession to make. If you would have caught me a few years back, you would find that the Sass architecture in my projects was pretty awful. I mean, there were so many issues, that to look back on them now, it would take a bottle or two of alcohol just to try and understand them. Due to this, I have spent hours upon hours researching principles and finessing my approach to come up with a strong Sass architecture. I know that there is no one-size fits all, especially since the type of projects that we all work on can be extremely different from one another. My hope is that as I share my knowledge and experience, you have some tangible take-aways to improve your own approach.

Enough about me though. Let us dive in.

Front End Methodologies

"Ummmm … wait a minute. I think you just wrote a typo. I thought we were going to talk about Sass Architecture?"

If that is what you are wondering after reading the previous header, do not worry. I know I have ADD, but I have a point here. Before we look into developing the best Sass architecture known to man, we have to start with a strong foundation. In order to do that it is important to understand some of the front end methodologies out there. The reason for this is because some of the finest minds on the web have put a lot of time crafting these to help people, like me, write better code. By taking some of the lessons we learn from their naming conventions, structures, and principles, we can apply these concepts to create a powerhouse Sass architecture.

SUIT CSS CSS Methodolgy

SUIT CSS

SUIT CSS, created by Nicolas Gallagher, at it's core is a methodology around component-based UI development. It relies on structured class names and meaningful hyphens. The primary division is between utilities and components.

Utilities

In SUIT, utilities have a singular structural or positional role. They can be applied to any element within a component.

Their syntax looks like this:

[u-][sm-|md-|lg-]<utilityName>

Components

Components, in SUIT, are design patterns found throughout the UI.

Their syntax looks like this:

[-][-descendentName][--modifierName][.is-stateOfComponent]

Our Findings:

Strengths:
Weaknesses:
Atomic Design CSS Methodology

Atomic Design

Speaking of design patterns, one of the biggest evangelists of these is Brad Frost. Shortly following the release of SUIT, in the summer of 2013, Frost wrote a article on his Atomic Design methodology that is still impacting the development world today. Now, I have no idea if SUIT helped shape Frost's principles at all, but there is a correlation in Frost's and Gallagher's take towards development in relation to patterns.

Let me state that design patterns were obviously not a revolutionary idea when SUIT and Atomic Design were released. Design patterns have been rooted in programming for years, gaining popularity in computer science back in the early 90s. Frost harnesses these ideas in his Atomic Design methodology: a methodology around creating design systems.

Inspired by chemistry, Frost draws parallels between living organisms and design patterns, creating five distinct levels in atomic design:

  1. Atoms
  2. Molecules
  3. Organisms
  4. Templates
  5. Pages

I am not going to get into the specific details of how these all break down, for Frost himself has written a book about it. With that said, I think there is a lot we can gather from the outline of his methodology. Let us break down what we can gather.

Our Findings:

Strength:
Weakness:
SMACSS Methodology

SMACSS

SMACSS (pronounced “smacks”) was created by Jonathan Snook. At its heart, it is a style guide that helps examine your design process in order to create a consistent approach when using CSS. The core of SMACSS is categorization. Snook claims that, “By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.” SMACSS believes the five categories that every design can be broken into is:

  1. Base
  2. Layout
  3. Module
  4. State
  5. Theme

Naming Conventions:

In line with these five categories, it sets out a naming convention for classes that fall into the layout, state, and module rules:

  1. Layout classes utilize
    l-
    or
    layout-
    as a naming prefix
  2. States classes utilize
    is-
    as a naming prefix
  3. Modules classes use the name of the module itself.
    1. Related Elements: it is worth noting that elements that relate to the core modules, utilize the name of the module as a prefix. For example,
      .button
      could use
      .button-icon
      .
    2. Sub-classing: in SMACSS, subclasses are similar to modifiers in SUIT. The main difference is that instead of using two hyphens, sub-classes utilize only one. The only difference between related items and sub-classes is that sub-classes are set next to the module class within HTML.

Our Findings:

Strengths:
Weakness:

The Wrap Up

If we were to take the strengths of all three of these front end methodologies and create a list, the key points that we would find are:

  1. Define clear coding methods
  2. Develop with patterns in mind
  3. Utilize name spacing
  4. Create a sense of hierarchy
  5. Create naming conventions that make sense
  6. Account for states and themes
  7. Abstract patterns from layout
  8. Account for responsive

We will take a look at why these principles are important to a strong Sass architecture in part two of this three part blog series.

You will not want to miss that!