Architecture with Sass – Modular Development

Having done many CSS websites, you might find that writing pure CSS can be daunting at the time. Sass offers a great way to organize our project, our Sass project into a scalable and maintainable code. I will guide you on how you can get started, and by the end of the read, you will be able to apply the architecture to your project.

The difference between CSS architecture and Sass is that CSS doesn’t have any real architecture. There is one file that contains all the CSS code, and it’s longer than the sleepless night where you supposed to fix the bug. Sass is a pre-processor to CSS. Basically, Sass is CSS with some extra superpower, and functionalities we can use.

With Sass we can divide our project into maintainable pieces, keeping the files organised, easy to read and find.

Architecture: File structuring

One of the biggest benefits of using Sass in our project is the ability to make appropriate folders and files and split them accordingly on what we will need, and what will make logic. With our beautiful @import functionality with Sass, we will not affect any of the performance. Each folder and file will be imported to one main app.scss file that will keep all of the files. Sass will compile everything and put it into one big CSS file, that we will connect to our project.

CSS is for browsers, and Sass is for developers.

Sass architecture varies from project to project. You should usually organize the files based on the project needs, however, there are some rules most developers follow.

Remember that this is only a guide on how you can utilize this in your project, but feel free to change it however you want. At the end, you should adapt to the project.




|– base/

|   |– _base.scss        # Base  

|   |– _typography.scss  # Typography rules

|   |– _normalize.scss   # Normalize/Reset

|   |– _settings.scss    # Settings

|   |– _variables.scss   # Variables

|   ...                  # Etc…


|– components or modules/

|   |– _buttons.scss     # Buttons

|   |– _carousel.scss    # Carousel

|   |– _modal.scss       # Modal

|   |– _forms.scss       # Forms

|   |– _navigation.scss  # Navigation

|   ...                  # Etc…


|– layout/

|   |– _grid.scss        # Grid system

|   |– _header.scss      # Header

|   |– _footer.scss      # Footer

|   |– _sidebar.scss     # Sidebar

|   |– _section.scss     # Section

|   ...                  # Etc…


|– pages/

|   |– _home.scss      # Home specific styles

|   |– _about.scss     # About specific styles

|   ...                # Etc…


|– utils/

|   |– _mixins.scss      # General Mixins

|   |– _functions.scss   # Sass Functions

|   ...                  # Etc…



`– app.scss             # Sass files combined


Don’t worry if you don’t understand why it’s structured the way it is yet. We will go over them in the upcoming sections.

Let’s look at each of the folders and file in out architecture.


The base folder is where we keep all of our project settings, defaults, resets etc.

The folder usually contains files such base.scss, settings.scss, variables.scss, reset/normalize.scss and many more.

The base.scss file contains the global element or global styles that will apply to the whole website. Same as you start writing your CSS file by targeting all elements * or the body tag, and you build up the tags from headings to anchor tags.

In the settings file, I tend to have variables for global adjustment such as line-height for the body, the font-size, colours, and so on.

When we start a project, we always have colours. I like to make a section of the colours I will use, such as the brand-colour, primary-colour, secondary-colour, anchor-colour and so on.

Settings file allow us the keep all the values in one file. If we want to change the body, we go to the settings file, and we adjust it to however we want. Same with colours, it’s much easier and cleaner to have these global files, in one file. Some people call it a config file and put it in utilities.


The layout folder will usually have the main components that are displayed on the page. They might be things like the header, footer, sidebar, grid system, some global CSS glasses like align-centre.

They will be used all on the website, they are the main block on the page, and it has some main functionality like the grid system. Layouts are basically like components, however, they are the main components of the site.


Components are awesome! Some developers name them modules, it’s totally the same thing. With this architecture, we can divide the components into small files. A component is something like a carousel, a blog post, media, buttons, forms and all these great things.

Each file has only one component. That is, to make the project clean and organized.

Each component will have its own variables at the top, so we don’t need to scroll down and find the values. For example, the way I like to do it ls like this:0

$bg:     #d8e0e5;
$color:  #ff7940;
$blanc:  #fff;
$noir:   #000;
$text:   #666c74;
$footer: #a3a9ab;
$duration: 0.3s;

.card {
       background: $blanc;
       margin-bottom: 40px;
       box-shadow: 0 0 20px rgba($noir, 0.1);
       transition: box-shadow $duration;
//more code




What’s beautiful about this is that we have most values at the top of the file, and we can easily change it. We can even make some math with Sass to have dynamic values that will update the whole code automatically.



Utilities if one of those folders that will be very dynamic. Utilities can have many files and folders, or only few, it depends on the scale of the project, and what it needs.

In utilities, I usually put in functions and mixins. However, there are times I will have to create a new mixins folder that contains all of the different mixins if this is a robust project.

I tend to keep media queries there, as media queries will use dynamic values, like the breakpoint will be saved in the variables folder, from mobile view to an extra-large desktop. Remember about having all set in one file that we can easily modify? That’s right. Media queries in Sass are fairly complicated if you never did them before.

Sass and BEM

BEM stand’s for Block Element Modifier. It’s a front-end methodology which allows you to write the code cleaner. Sass and BEM form a very strong team.

You can make a file in components, for example, names helpers. In the helper’s file, you can write some extends for buttons etc. Something that will be used across multiple times, of course, you don’t want to copy and paste it every time.

What makes Sass and BEM special is the way BEM works and the functionality that Sass offer us. Take a look at this:


<nav class="navigation" >

<ul class="nav-list">

                <li class="nav-list__item">

                <a href="" class="nav__link"></a>


                <li class="nav-list__item">

                <a href="" class="nav__link--active"></a>


                <li class="nav-list__item">

                <a href="" class="nav__link"></a>




.navigation {


.nav-list {

                &__list {

                                &__item {



                &__link {

                                &--active {





Which print this:



.nav {


.nav-list {


.nav-list__item {


.nav-link {


.nav-link--active {



See how easy this is? It will save a lot of time. However, this is a small picture of what Sass and BEM together can do. As you learn more about Sass, and possibly about BEM, you will find many ways on how to utilise this together.


Other developers write it different

We all differ, and we all like to do things differently. Every project is different that we work on, they might be similar, but most of the time, they will require some special tweak to make it unique.

I put a strong emphasis that this is only a guideline for Sass projects. You might do it completely different than I did, and completely different than other developers did it. Each action has its own reason. You might find that this isn’t the best for you, so you might try and modify it to your needs.

If you give 10 developers to write the same functionality, they will write it in 10 different ways. It’s true for everything. There are many front-end methodologies out there, and many ways you can modify it to your needs.

You might see a code that has a prefix with a letter such as

c-modal, l-centre, g-column

and so on.

There are many ways. The above code did frustrate me a long time before I figured out what it meant,  so I’ll explain to you here

The c represents the components folder. You can use the same for layout, with a prefix of l-align-centre and so on. It’s up to you.

In this case, the modal is in the components, the modal itself is a component. If we want to centre something, we are adjusting the layout probably, so we can refer to our helpers in the layout folder, and get l-centre, or g-column for the grid.

The letter prefix is used for an easier understanding of what the class do. If we put a g- as a prefix, which means for the grid, straight away we will know that this is about the grid.

Every developer will use some of his own techniques and logic behind. My recommendation is to look at many sites, at many developers and see how they are using their project. That way you will have a diversity of how you can start your own project.

How many folders do I need

Usually, the project structure varies from project to project. You might have more folders or less. On average there should be about 5folders, however, this is an average. You might need 2 or 10, it’s up to you, there is no or right answer to this. This code is one code from my project, however, I tend to change the architecture and adapt it to the project. Sometimes I have only 4folders, the other time’s I might have 8.

It really depends. Do what gets the job done.



As you see, the Sass architecture isn’t anything crazy, and yet is very powerful. This is based on my personal preference, and if you get my GitHub account and look in my project folders, you will see that every project has a different architecture. That is because the files are adapted specifically to the project.

There is no right or wrong rule on how you do this. The key to really understand this is to practice. I have made a lot of Sass structures, and each time I understood it more because I knew what I could change for the specific project.

Start right now

However, when working in a team, make sure you all are happy with the architecture and you understand it well.

What are your thoughts on Sass architecture? Comment below! 🙂

Meet the author

Meet the author

Aurelian Spodarec

Front-end WordPress developer that blogs about web development. I like using the right tools for the job. In my spare time, I enjoy cooking healthy food and then eating it. Delicious!