People use SASS for many reasons. Some of these reasons are:

• It makes things more organized than having just one big CSS file
• Mixins can be very useful to save time
• Being able to utilize variables allows for fast, global changes (if implemented in such a way)
• The separation of files makes it easier for multiple people to work on the same website at once

But what IS the best SASS structure?

Well, in all honesty, there is no “best structure” You can setup your directories and files as you feel fit.

After all, the entire point of SASS is to help make things easier for you and others. So setup whatever you are comfortable with.

Now, this structure varies greatly depending on how large the project is and how modular you want to go.

SMACCSS – Scalable and Modular Architecture for CSS

If you take a SMACSS approach, then you will likely have many folders with many scss files, as you attempt to make things as modular as possible.

You’ll likely have the typical categories: Base, Layout, Module, State, Theme

This is a nice approach in the sense that you and your team will have comformity and an easier time sharing the SASS workspace while avoiding conflicts (awesome for an Agile / SCRUM environment). However, it can be overkill for many projects.

One SCSS Per Page

Another approach that is taken often times, is creating a base and layout that contain the building blocks for the general layouts themselves, and then creating additional SCSS files for each page that requires additional, non-resuable, custom CSS.

This makes it easy to find all of the elements on a specific page rather than having to dig through lots of different folders and files.

The downside? It’s less modular.

My SASS Structure

The great thing about SASS, is that, in the end, YOU determine your structure. Everyone organizes things differently, and if you so chose to, you can make your structure easily.

Here’s MY SASS structure.

Directories
Layout – Contains the building blocks of the actual layout(s). Such examples are “footer”, “footer nav”, “header”, “header nav”, and “side menu”, as well as a special file called “base”, which includes miscellaneous layout css modifications. Within this folder, we have the Helpers folder that includes things like a CSS reset, REM sizing conversion, and border box sizing. The “Helpers” folder contents could arguably be integrated into “base.scss” to cut down on the modularity if you so wish.
Mixins – Self explanatory. It contains mixins to do things like box shadows and border radius with all of the special browser prefixes.
Modules – Reusable pieces of code, such as “carousel”.
Thirdparty – Any styling not created by you or your team (such as Bootstrap css).

In the root directory, there are 3 key files.
_settings.scss – Variables get stored here that can be used throughout your project for fast modifications. For example, different media query breakpoints, colors, or font sizes.
_shame.scss – As the name implies, this SASS file holds any “hacky” workarounds you must use to enforce browser comformity between certain browsers (IE!) and browser versions (older IE versions!).
main.scss – This file just connects all the other files together through @import’s.

And…that’s my structure! It isn’t overly modular and it definitely has some overlap, but it works.

If interested, you can download this structure here. I’ve included some mixens, a css reset, border box styling, etc.

If you’ve never created your own structure though, then I’d recommend doing so, as it’s a good learning experience.