Css style

CSS Architecture Style Guides for Front End Developers

Profile picture of Ian Holden HackerNoon

Ian Holden

I’m a software engineer who enjoys learning and writing about frontend and backend development.

Have you ever worked on a large project where there’s a clear structure in place for the JavaScript source files, but when you need to make a change to the CSS, you’re greeted with a mess of unstructured CSS?

You know which CSS attribute you need to add or change, but in code you are careful because CSS attributes are overridden in several places and in some cases there is


flags used. You are afraid to modify the code for fear of breaking some existing styles. So naturally you create a new rule that has great specificity and only adds to the mess you were greeted with in the first place.

This is a problem that many projects suffer from.

Understanding how to organize CSS in your project’s code base can be invaluable when your project begins to scale or when new front-end engineers join the team. I would like to introduce you to different ideas that can help you create a stronger CSS architecture.

Why do we need a strong CSS architecture?

The foundations of a solid CSS architecture can support the project as it begins to evolve and grow. If these foundations have not been built with thought or planning, it is very likely that in the future your project may metaphorically fall apart.

What I mean by this metaphor is; Although CSS probably won’t break your system like a JavaScript error would, it can create different issues that make working on the project very difficult. If you have a team of engineers who are not confident in adding or changing CSS in the project, they are more likely to introduce bugs. These bugs will find their way to your end users and the success of the project may be affected.

It is essential to start a project with a solid CSS architecture in place because it’s much easier to write bad CSS than to delete it.

My impression is that CSS is not as widely respected in the front-end space as other disciplines. Why do we take so long to familiarize ourselves with the latest JavaScript frameworks, but also insist on getting by with a loose understanding of CSS? HTML and CSS are the building blocks of the web, but we settle for an average understanding.

It’s something I think we’ve all been guilty of! This is something I would like to change.

What CSS architectures can we use?

There were a number of CSS architectures that stood out when I started researching this topic. They were:

  • OOCSS (object-oriented CSS)
  • SMACSS (scalable and modular architecture for CSS)
  • ACSS (Atomic CSS)
  • BEM (block element modifier)

I don’t want to describe them in too much detail as there are already great resources available online. Instead, you can find a brief description of each below and a link to more information on each methodology.

What is BEM (Block Element Modifier)?

BEM stands for Block Element Modifier and is a CSS architecture way to encourage the use of a consistent naming convention when creating your styling classes.

The naming convention recommended by BEM is block-name__element-name–modifier-name or:

For more information on BEM, I recommend reading BEM 101.

What is OOCSS (Object-Oriented CSS)?

OOCSS stands for Object Oriented CSS and is a CSS architecture way to encourage the use of abstraction to separate structural and visual styling as well as to remove duplication from your CSS.

OOCSS encourages you to change the following example to something like this…

.button {
    padding: 10px 16px;
    color: blue;
.h1 {
    font-size: 2em;
    color: blue;

…to something like this…

.button {
    padding: 10px 16px;
.h1 {
    font-size: 2em;
.primary {
    color: blue;

With our new abstraction, we can assign the ‘primary‘ the class to both


elements and it will be given a color of ‘blue‘. This helps us keep our stylesheets nice and dry (don’t repeat yourself).

For a more detailed guide to OOCSS, I recommend reading An Introduction To Object Oriented CSS (OOCSS).

What is SMACSS (Scalable and Modular Architecture for CSS)?

SMACSS stands for Scalable and Modular Architecture for CSS. It requires styles to be built under five different categories: base, layout, module, state, and theme.

  • Based styles should contain your default CSS styles. These styles will be used on all elements of the website/app.
  • Arrangement styles should contain element styles designed to separate the page into its structural components. Styles for elements such as header, footer, and grids should be defined here.
  • Module the styles should contain the styles of the reusable elements on the website/app.
  • State styles should define the different states of different elements on your website/app. Styles such as ‘is-active’, ‘is-disabled’ and ‘is-success’ should be found here.
  • Theme styles should dictate how your elements look. They should go beyond the basic styles and start injecting your project’s brand and style into the website/app.

For a complete overview of SMACSS, read its creator’s online guide at SMACSS.com.

What is ACSS (Atomic CSS)?

ACSS stands for Atomic CSS and focuses on creating many small CSS utility classes that you can use in your HTML code. It is similar to OOCSS in that they both recommend separating duplicate property-value pairs in their own rules. ACSS could be considered a more extreme version of OOCSS though, as it encourages you to create styles at the smallest possible level.

Here is an example of style rules you might find in a project that uses Atomic CSS:

/* Colours */
.color-primary { color: blue; }
.color-secondary { color: purple; }

/* Margins */
.mt-1 { margin-top: 5px; }
.mt-2 { margin-top: 10px; }
.mb-1 { margin-bottom: 5px; }
.mb-2 { margin-bottom: 10px; }

ACSS is also different from OOCSS in that it recommends the use of CSS properties in the CSS selector naming convention. For example, in OOCSS you can target a selector named


to change the color of your elements to a nice shade of blue. In ACSS you can target a selector named



To learn more about ACSS, I recommend reading Let’s Define Exactly What Atomic CSS is.

Which CSS architecture to choose?

The short answer – it doesn’t matter.

There are positives and negatives to each different architecture described above. Different people will have different views on which they prefer.

The most important thing is to make sure your team has agreed on a consistent format to use before you start writing CSS. This format can be one of the architectures mentioned above, a mix of different architectures, or something you create yourself.

The engineering team working on the project must understand this format so that any new CSS written follows the style you have chosen to follow. Preferably, the architecture should be explained in written documentation. New engineers joining the team should be able to quickly and easily learn about your chosen architecture.

Apply a consistent style

Once you’ve defined some rules for how your styles should be written, you’ll want to apply them. Whether done manually or through an automated process, you’ll want to ensure that your code base’s CSS is written consistently over time.

Manually apply your code style

You can do this manually by checking for new additions to the code base when reviewing pull requests in your git workflow. If you can see that a new CSS rule is added that uses the


flag or create new code instead of using an existing utility function which will give you the same result, you should probably mark this code as changed.

It’s optimistic to assume that every member of your team will have a full understanding of the CSS architecture you’ve chosen. Humans make mistakes, and it’s impossible to ensure that every pull request will be reviewed without the whiff of code escaping.

We need something more reliable.

Automate the application of your style of code

Just as we can use linters to review our JavaScript code, we can now do the same for CSS. PostCSS is a tool that helps engineers write CSS and use plugins to enhance or enhance it. PostCSS offers a host of plugins that include tools to help us do all sorts of things to our CSS like auto-prefixing, linting, minification, and many more.

Automating your processes like this will help reduce the number of issues that creep into your manual code reviews and give the team more time to focus on the code they’re working with.

I would recommend learning more about PostCSS by visiting the PostCSS repository.


Whichever way you choose to architect your project, you need to make sure you don’t forget your CSS. You should try to maintain a consistent style in your CSS code that makes it easier for new engineers to get started and allows them to make changes with confidence. Make sure these rules are documented and enforced, preferably in an automated way.

The upfront time spent creating a solid set of rules that govern how you write CSS will far outweigh any problems you might face in the long run if you don’t invest that time now. You want new code to produce new functionality. Don’t let small bugs take up the majority of your engineer’s time and energy.

What new CSS tools and architectures are you currently discovering? I would love to hear your thoughts in the comments section.

Previously posted on https://ianholden.co.uk/blog/css-architecture-bem-oocss-smacss-acss-and-why-we-need-it/

Profile picture of Ian Holden HackerNoon
through Ian Holden @ianholden.I’m a software engineer who enjoys learning and writing about frontend and backend development.

Read more