How Evernote handles their Sass Architecture

Managing a large website like Evernote.com can be tricky and it helps to have a thoughtful architecture when managing files. Implementing Sass in our build was no different. We needed a methodology to manage how we styled our pages using Sass.

After reading the book SMACSS, there were several ideas outlined in the book seemed to fit well with how we could manage our files. When creating our Sass architecture we leveraged a few of the ideas from the book to help outline our documentation.

In order to be able to reuse styling throughout various pages on Evernote.com we break everything into modules. This can be tough to manage if there isn’t a clear understanding and documentation between all the engineers working on the build. In order best organize all these modules we’ve created four main directories where these files can live. Using the directories: base, layout, modules, and themes helps organize our files in a project and compile CSS into a clean, logical file. Each page has a Sass file created that acts as a project file that imports the individual modular components from base, layout, modules, and themes that are needed to build the particular page.

Sass directories

1. Base: the base directory contains Sass files that start a page. These files are typically things like any vendor dependencies (Compass, Foundation) or any of our own authored dependencies (mixens, variables, extends). In the base directory we will also reset a default style for the browser.
2. Layout: the layout directory is a good place for us to control our grid system and any large page specific layout styles.
3. Modules: the modules directory contains the majority of our files because we like to break our styles into small components so we can leverage them throughout multiple pages on our site. Each page is typically made up of at least 5 modules. Some of the more common modules will include items such as header, footer, navigation and content blocks.
4. Themes: the themes directory contains any specific styles that a page may need to overwrite a style in the layout or modules without having to effect other pages referencing these layouts or modules. For example the header in your website maybe green throughout a website or application but on a specific page we want it to change to a grey background, that’s where the themes files come in handy.

Individual pages

In order to compile a final CSS file for a page we have a Sass file that calls the various dependencies the page needs from the four directories. These files help us understand and control the dependencies each page needs for it’s final styling.

This is what a typical page specific Sass file would like:

Benefits to organizing our Sass files

By using this structure in our Sass build we’ve found it to help write cleaner code. It’s allowed us to become more agile in our development and leverage modular reusable code. The final compiled CSS file size is kept smaller because we are only using styles that are necessary for a particular page. Finally it’s helped our code stay consistent between each of the engineers writing the code.

Keeping the build clean

After using this methodology in our current build for Evernote.com we’ve found there can be a lot of modules and layout files that end up getting old and we may not need them anymore. Having unused files in your codebase isn’t the end of the world but it can slow down your compiler when it’s watching all these files. So in order to help keep our codebase clean I created a Grunt task (Sassy-clean) that checks all the Sass files in the four directories to see if they are referenced in any of the individual pages, if they aren’t referenced they are deleted. This has significantly helped us keep our codebase lean without having to manually check to see what we can get rid of.

An example on Github

We have provided an example of our Sass structure to help better understand how everything is organized. Feel free to fork it and use it in your own project.