A Look at Different Sass Architectures

Vinay Raghu
Vinay Raghu

As the size and complexity of a project grows, you require some sort of logic to structure your Sass files. It helps to follow some agreed upon guidelines for creating files and folders when working in large teams and projects. Below is a review of some of the techniques in use today.


Bootstrap’s intention is to be a UI library for web developers to quickly get off the ground. It is logical for them to group all variables in a single file and keep all the mixin logic hidden. Their Sass architecture mimics this idea. Each component gets its own Sass file and there’s a ./_variables.scss file, which allows you to control all the variables involved with your project.

Bootstrap’s Sass architecture is unique in how it lays out its mixins. There’s a ./_mixins.scss file. This file imports all files from a mixins folder, which contains a separate file for every mixin used. Although button styles are defined in ./_buttons.scss, the mixins used for it are imported from ./_mixins.scss. This, in turn, imports the button mixins frommixins/_buttons.scss. Yo Dawg!

In addition to component-level mixins, the mixin folder also contains global mixins such as mixins/_border-radius.scss and mixins/_responsive-visibility.scss. Although bootstrap’s mixins are not overly complex, this architecture is better suited for a project where the mixins are really complex and require that they be broken down into smaller bits. Or in cases where you want to keep that logic hidden from visual styles of components. In conclusion, this architecture works best for Bootstrap but might not work for your sass project.

Here’s how the folder structure looks:

|– bootstrap.scss   # Manifest file 
|– _alerts.scss     # Component file 
|– _buttons.scss    # Component file 
|– _mixins.scss     # Mixin file – imports all files from mixins folder
|...             # Etc..
|– mixins/
|  |–  _alerts.scss # Alert mixin
|  |– _buttons.scss # Button mixin
|  |...           # Etc..

Zurb Foundation

Foundation has a well thought out Sass architecture and it works beautifully for customizing, which is one of its biggest strengths. There’s a settings.scss at root level, which allows you to override any variable used for building components. However, each component file contains variables specific to that component.

Foundation also abstracts functions used in the project in a separate functions.scss file. This is good because these functions are framework specific and you should not be editing this file.

All global mixins such as border radius and transition effects are available in components/_global.scss. They are logically structured as follows:

- Import - global mixins
 - Component specific variables (`$button-tny`, `$button-margin-bottom`) 
 - Component specific mixins
 - Extends - (not the @extend but actual style definitions, where mixins are called)

All component-specific variables are defined as !default, so that they can be overridden using the _settings.scss. If you prefer to keep it simple, you can just change the variables in _settings.scss and call it a day. If you feel more adventurous, you could play with component-specific variables and easily be able to change how your components look.

Since their components are built out of mixins and variables, it allows for maximum flexibility. A lot of sites built using Foundation don’t end up looking the same.

You can adopt foundation’s Sass architecture for most small to medium websites. It becomes very easy to get into the scope of any component and have all required variables, mixins, and extends within the same file.

Here’s how the folder structure looks:

|– foundation.scss           # Manifest file 
|– foundation 
|  |– _functions.scss        # Library specific functions 
|  |– _settings.scss         # Change variables for the entire project
|  |– components
|  |  |– _buttons.scss       # Component file (will import _globals.scss)
|  |  |– _globals.scss       # Global mixins
|  |  |– _alerts.scss        # Component file (will import _globals.scss)

Dale Sande’s Architecture

Dale Sande, in his presentation “Clean out your Sass Junk-Drawer”, recommends a modular approach to organizing your Sass files. This comes in handy in enterprise-level projects where the number and visual complexity of modules can be pretty high. This approach helps retain all logic related to a module within its own folder, which allows sub-modules to extend and reuse styles in a scoped fashion. It can also be useful in small to medium projects, if you prefer separating presentation from Sass logic in your files.

One of the major advantages to following Dale Sande’s approach is the fact that it makes it easy to create a separate stylesheet for a particular module. Inside your project, you could load one base stylesheet that contains global styles and load another stylesheet specific to the module. This helps remove a lot of bloat from the code, improving performance and load speed.

Here’s the folder structure:

|– style.scss                        # Manifest
|– modules/ 
|  |– registration/                  # Sub Module
|  |  |–  _extends.scss              # Functional 
|  |  |–  _functions.scss            # Functional 
|  |  |–  _mixin.scss                # Functional  
|  |  |–  _module_registration.scss  # Imports functional partials and contains presentational 
|  |  |–  _module_personalInfo.scss  # Imports functional partials

Style Prototypes

Style prototypes, by Sam Richard, is a brilliant tool and set of guidelines for design in the browser using Sass and Compass. In this architecture, components are logically grouped under specific folders such as base, components, layouts (SMACSS) or atoms, molecules, and components (atomic design).

Further, each component gets its own set of partials: _variables.scss, _mixins.scss, _extends.scss and a manifest file (_buttons.scss, _alerts.scss etc).

This approach has a couple of disadvantages though:

  1. Compile time – More files require more time to get compiled
  2. It might require a lot of file switching when you build components initially. But once you are done, its a breeze to maintain or make changes.

The benefit here is the ability to work on a single portion of a module. It clearly demarcates configuration (variables), functional (mixins, extends), and presentational (component partials) portions used to design a component. Global configurations are kept separate from component/module level configuration.

This separation helps maintain sanity in medium to large projects, where you have multiple teams working on modules. It also becomes easier to create module specific stylesheets, when required.

Here’s the folder structure:

|– style.scss    # Manifest
|– partials/
|  |– base/
|  |  |– _content.scss
|  |  |– content
|  |  |  |– _variables.scss    # Component specific variables  
|  |  |  |– _extends.scss      # Component specific extends
|  |  |  |– _mixins.scss       # Component specific mixins
|  |– components/
|  |  |– _message.scss
|  |  |– message
|  |  |  |– _variables.scss
|  |  |  |– _extends.scss
|  |  |  |– _mixins.scss
|  |– global/
|  |  |– _variables.scss
|  |  |– _extends.scss
|  |  |– _mixins.scss
|  |  |– _functions.scss
|  |– layouts/
|  |  |– _article.scss
|  |  |– article
|  |  |  |– _variables.scss
|  |  |  |– _extends.scss
|  |  |  |– _mixins.scss


I think Hugo does a great job of covering a SMACSS-based approach, which you can read about in his Sass architecture post, so I won’t discuss that here. There’s also a handy SMACSS starter kit by Mina Markham available.


In this article, we looked at different ways to structure your Sass files. To decide which method to use, you need to weigh your options between complexity, compile time, and personal preference.

This becomes tricky when working on teams. Make sure everyone feels comfortable with your approach and feel free to tweak methodologies to suit your specific circumstances.

I like the Style Prototypes architecture best because it suits the way I think. The important thing to note is

The deeper you nest, the longer it takes to compile.

Do let us know your project’s Sass architecture in the comments section.

Frequently Asked Questions (FAQs) about SASS Architectures

What is the significance of SASS architecture in web development?

SASS architecture plays a crucial role in web development. It helps in organizing your stylesheets, making them more maintainable and scalable. With a well-structured SASS architecture, you can easily manage your CSS code, making it easier to understand and modify. It also enhances the performance of your website by reducing the size of your CSS files and making your code more efficient.

How does SASS architecture differ from traditional CSS?

SASS (Syntactically Awesome Stylesheets) is a preprocessor scripting language that extends CSS. Unlike traditional CSS, SASS allows variables, nested rules, mixins, functions, and many other techniques that allow you to write CSS in a more concise and flexible way. This makes your stylesheets more readable and maintainable.

What are the different types of SASS architectures?

There are several types of SASS architectures, but the most common ones are the 7-1 pattern, SMACSS, and OOCSS. The 7-1 pattern divides the SASS files into seven folders and one main file to import all other files. SMACSS (Scalable and Modular Architecture for CSS) categorizes CSS rules into five types: Base, Layout, Module, State, and Theme. OOCSS (Object-Oriented CSS) encourages code reuse and faster and more efficient stylesheets.

How can I implement the 7-1 pattern in SASS?

The 7-1 pattern is a popular SASS architecture that organizes your SASS files into seven different folders: base, components, layout, pages, themes, abstracts, and vendors. Each folder has a specific role and contains specific types of styles. To implement this pattern, you need to create these seven folders and one main file (usually named main.scss) to import all other files.

What is the role of the ‘base’ folder in the 7-1 pattern?

The ‘base’ folder in the 7-1 pattern contains the fundamental styles of your website. It usually includes styles for standard HTML elements like body, headings, links, lists, etc. These styles act as the base for other styles in your website.

How does SMACSS differ from the 7-1 pattern?

While both SMACSS and the 7-1 pattern aim to organize your stylesheets, they do so in different ways. SMACSS categorizes CSS rules into five types, while the 7-1 pattern organizes SASS files into seven folders and one main file. The choice between the two often depends on the complexity of the project and personal preference.

What is the advantage of using OOCSS?

OOCSS, or Object-Oriented CSS, promotes code reuse and faster, more efficient stylesheets. It encourages you to write styles based on objects, which can be reused throughout your project. This reduces the amount of code you need to write and makes your stylesheets more maintainable.

Can I combine different SASS architectures in one project?

Yes, it’s possible to combine different SASS architectures in one project. For example, you can use the 7-1 pattern to organize your files and SMACSS to categorize your CSS rules. However, it’s important to maintain consistency in your code to avoid confusion.

How can I optimize my SASS architecture for large projects?

For large projects, it’s crucial to have a well-structured and scalable SASS architecture. You can achieve this by using architectures like the 7-1 pattern or SMACSS, which organize your stylesheets into manageable sections. Also, using techniques like nesting, variables, and mixins can help to keep your code DRY (Don’t Repeat Yourself) and more maintainable.

How does a well-structured SASS architecture improve website performance?

A well-structured SASS architecture can improve website performance by reducing the size of your CSS files and making your code more efficient. By organizing your stylesheets and eliminating unnecessary code, you can reduce the amount of data that needs to be downloaded, resulting in faster load times. Additionally, efficient code can reduce the time it takes for the browser to render your website.