It’s never too late — Switching from CSS to SASS Midway

SASS is great. Ever since I was introduced to the concept, I haven’t gone back to CSS (otherwise known as Syntactically Terrible Style Sheets) for any of my projects. My sincere hope is that in a couple years, writing plain CSS will be seen similar to trying to code with punch cards. It’s just the worst.

Before you continue, if you’re not someone that already sees the virtue in SASS, then duel me then this article isn’t for you. Go google it and come back when not having SASS is an actual problem for you. Additionally for this article, when I mention “SASS” I really mean the .scss version. In this version, CSS can be considered valid SASS(.scss); so it makes the conversion easier both in setup and in helping your team make the adjustment.

Now that my opinion is concisely and painfully clear, let’s get down to business. Literal business. If you’re put on a project, chances are you might be inheriting someone else’s code. If this project happens to contain HTML, it will also probably have CSS with no pre-processors in sight.

Other than to find a different day job, you still may have an option:

Introducing: (ba – da – da – da – duh – dahhh)

How to Switch From CSS to SASS Midway Through a Project

Step 1: Evaluate if it’s worth it ( hint: it almost always is)

A good candidate for SASS conversion therapy will be easy to spot. If your project is:

  • going to continue to grow
  • having visual consistency issues
  • having CSS file size issues due to WET code
  • and/or: your CSS is poorly documented in a way that makes it really hard to find if what you want to do has already been done

–> Convert to SASS

However, if your project is:

  • Already completely finished (using CSS) with no plans to add features
  • Requires an incredibly little amount of CSS
  • has no time or resources in the present to be able to implement time & resource saving changes for the future

–> Sadly, it’s probably not worth it

It doesn’t really make sense to put in the effort. If you have time or just want to, it can’t hurt (except maybe in a very minor performance-decreasing way for the small CSS file case), but it’s either much too late, you have too tight of a schedule,  or it has no actual benefit.

Step 2: Sell it to the suit

To do the conversion, it’s going to take time and resources. This means it will cost money. Money that your team/clients don’t want to spend.  In my opinion, the main problem of selling a SASS conversion is that if you do it right, the styling should look just about the same after the conversion as it did before. There should be almost no visual differences, and if it looks like nothing has changed– why should time and money be spent on that?

  • Maintainability –> Sass is structured with variables, mixins, functions, and nesting. All of these features make the code DRY-er so when changes need to be made, it should be easier, more correct, faster, and overall much cheaper (– $$$$).
  • Visual Consistency –> more and more, visual design matters. Maintaining a clean brand matters. If your site is using 5 different shades of pink instead of the brand’s defined pink, your site will look sloppy. And customers notice sloppy (– $$).

Maintainability can save a lot of time and money. For starters, think about how many changes you’d have to make in your CSS right now if the client just decided to switch their primary color from pink to yellow. That could be done in one line using SASS. Scale those kind of changes up, and you may end up with a good sum of money.

Time to Get Cracking – I hope you REALLLY enjoy organizing things
It’s going to be slightly tedious, but keep future-you in mind, and it should be OK.

Step 3: Break down your project visually

Before you touch any part of the code, go and look at your current project. Start writing down different components that are reused throughout the app. — buttons, forms, images, special items, etc. It helped me to make drawings of the components and organize them accordingly. I had 4 different types of buttons, so I drew them and circled them in a potential button component grouping.


This will come in handy later.

Step 4: Backup your old CSS

People make mistakes. You need to make sure you have a way to get back just in case you royally mess something up in your SASS conversion. Additionally, it is extremely useful to have a copy of the old CSS (oldStyle.css) at your fingertips so you can continue comparing your SASS-generated CSS with the original as a visual check. And on top of all of this, use version control to commit every step of your SASS conversion so you can rollback easily.

Step 5: Setup SASS in your Project

I’ll leave this to the pros: and/or

Make sure to have some sort of sass-watch so that it auto-compiles. I recommend using compass. This really speeds up development, and also helps you know immediately when you messed things up.

Step 6: Decide & Setup SASS File structure

SMACSS might be a good idea. Or you could also mimic Foundation Framework’s file structure. You should at least have a place for your components and variables as well as a base file to glue them all together. For variables, I would recommend separate files for: colors, typography & font sizes, z-indexes, and screen breakpoints. When thinking about your components, you can now utilize Step 3’s results. Make some blank files for your project’s specific components.

This is the file structure that SASS recommends:


I usually pick and choose what I think works for my project.

Step 7: Utilize a CSS – SASS converter

Copy your old CSS file and paste it into .

Be sure to convert it to SCSS not SASS as mentioned in the beginning. After saving the new .scss file and putting it in your project, you’ll see that it compiles into .css. Link your project to your new SASS generated CSS and do a visual inspection. Sometimes these converters mess up if your CSS has multiple selectors. (eg. green-button, blue-button { … }). However, most of the time they do a pretty good job of auto-nesting all of your CSS, saving you the trouble of doing it manually. If you’re getting bad results, try to go through your CSS and nest your classes where it makes sense manually.


Step 8: Extract the constants into SASS partials


The goal here is to make all of our references to hard-coded color values into references to SASS variables for that color. First, let’s find all the colors that are being used. You can use this nifty online tool: You might find in this step, that you have colors that are near identical but have different hex values. Consolidate these and congratulate yourself on one of many visual consistency improvements.


Now in your color variable file (colors.scss), start by naming your colors and assigning them to the hex value. It’s a good idea to name the colors unique identifying names (eg. “$cornflower”) and then later assign them to more semantic names (eg. “$primary-button-color = $cornflower). If you need help coming up with color names,  I found this tool useful.

For example:

/* _colors.scss */
/* unique color names */
$cornflower:  #6195ED;
$deep-ocean: #14428F;

/* semantic color names */
$primary-button-color: $cornflower;
$primary-button-shadow-color: $deep-ocean;

And once you have your colors uniquely named as well as semantically named, go through all of your SASS code and replace the colors with their corresponding semantically named color. This helps make the code readable as well as modifiable.

Typography & Font sizes

Search through your SASS file, and find all the font-size stylings. They might vary all over the place, so this is a good time to try to see if you can come up with standard sizings.  I also take the opportunity to declare my font families.

//declaring font-face
$global-font-family: "HelveticaNeue";
$global-font-style: normal;
$global-font-src: 'local("Helvetica Neue"), url("../fonts/HelveticaNeue.ttf") format("truetype")';

 font-family: $global-font-family;
 font-style: $global-font-style;
 src: $global-font-src;

// using your font-face
@mixin Helvetica-Neue {
 font-family: "HelveticaNeue", HelveticaNeue, sans-serif;
 font-style: normal;

@mixin Helvetica-Neue-Italic {
 font-family: "HelveticaNeue", HelveticaNeue, sans-serif;
 font-style: italic;

@mixin Helvetica-Neue-Bold {
 font-family: "HelveticaNeue", HelveticaNeue, sans-serif;
 font-weight: 600;
 font-style: normal;

@mixin Helvetica-Neue-Bold-Italic {
 font-family: "HelveticaNeue", HelveticaNeue, sans-serif;
 font-weight: 600;
 font-style: italic;

// font sizes
$font-size-small: 1vmin;
$font-size-regular: 2vmin;
$font-size-large: 3vmin;
$font-size-x-large: 4vmin;
$font-size-xx-large: 5vmin;
$font-size-xxx-large: 6vmin;
// semantic font sizes for special cases
$font-size-title: 3.2vmin;
$font-size-description: 2.5vmin;
$font-size-disclaimer: 1vmin;

Layout and Breakpoints

Do a similar search, extract, and replace for commonly used layout values. For example if you commonly pad items with 2em, consider making that a variable.


By making a partial to store your z-index variables, you can cut out the guess work that goes along with z-indexes. Make sure EVERY z-index corresponds to a variable. This way, when you have to add a new one, you can make sure you aren’t stepping on the toes of a previously declared z-index.

Step 9: Straighten out your SASS spaghetti

OK. So now we have working SASS, and it uses beautifully declared partial files that store our variables. If you don’t have any time left, you could even stop here and count it as an improvement.

If you have more time, start separating your code into the different components you determined you have in Step 3.

Step 10: Kill the redundancies! Kill the redundancies!

This part is a little more specialized. You will have to go through each of your newly separated SASS component files and see if you can further nest styles or see if there are redundancies in the code such as declaring the same styles in several media queries even if they all inherit from a base styling.

This is a great place for improvement, but it’ll take a while to polish. Make sure that you continually test against the original oldStyle.css to make sure you aren’t breaking the style.

Step 11: Preach the good word of SASS

Now that the coding is done, you have one final important task: Talk to your team. If you’re the only one who got the SASS memo and all of a sudden Bob, your coworker, decides to just create another separate CSS file so he doesn’t have to learn what’s going on with SASS, (typical Bob) you will have wasted your time. Or imagine if he starts putting in random font-sizes or hard-coded colors. It would defeat the entire point of this process! Sit down with other people on the project and offer to show them why SASS can be good for the project and lead them to good resources.


CSS Family Guy Gif credit:

Leave a Reply

Your email address will not be published. Required fields are marked *