When I was first learning Sass, I experienced a bit of frustration trying to get started and get my environment set up. This blog post is intended for Sass absolute beginners who are looking to get set up and write their very first Sassy CSS.
Sass stands for Syntactically Awesome Style Sheets, and it is an extension of CSS (Cascading Style Sheets). The latest version of Sass is saved with a
.scss extension vs. CSS’s
Sass builds on CSS and provides a ton of extra features to improve efficiency, productivity, and help you and your codebase subscribe to the “don’t repeat yourself” (DRY) principle.
Installing Sass via Mac command line is simple. Sass has a Ruby dependency but if you’re on a Mac, you’ve already got Ruby installed! Simply type
gem install sass in your command line, or if that doesn’t work, try
sudo gem install sass. To confirm that your installation was successful, type
sass -v and you should see the current version of Sass that you’ve just installed.
If you’re having problems, or to install Sass with other operating systems, see the official Install Sass documentation.
There are many ways to think about and to structure your Sass files, and I’ll touch on those in a bit, but in order to get started, all you really need is a single
.scss file, and you can name it whatever you want, for example,
style.scss. Create a new file with your favorite code editor and give it the file extension
Depending on your project setup, you may or may not need to convert your
.scss files to
If you have a Ruby on Rails project, Rails will compile Sass for you so you won’t have to do it manually. Similarly, when using React, there are packages you can install that will manage your Sass files for you.
To manually compile your Sass to CSS, you can set up your workflow so that Sass automatically keeps track of your Sass file and converts it to the CSS version every time a change is made. In order to do that, you need to have Sass “watch” for changes. Since we are starting simple and only have one file, set up Sass to watch for changes by typing in your command line, in your project folder:
In the code above, you are telling Sass to watch the file
style.scss, which is where you will be writing your Sassy CSS, and to convert it to a file called
style.css which will be created the first time a change happens. You do not need to create the
style.css file manually.
And that’s it! Every time you add or make a change to your
style.scss file, Sass is watching and knows to update the corresponding file, in this case
style.css. If at any time, you want to change the files that are being watched, you can run
sass --watch again with the new filenames.
As your project grows and you amass multiple SCSS files, you’ll want to set up your
sass --watch to watch an entire directory vs. a specific file, but that is a blog post for another time. You can also check out this blog post on Sass Break that goes into more detail about the different ways you can use
We made it! It’s time to write some Sassy CSS!
The core of writing CSS has not changed, and a lot of the styles you’ll write will likely look like vanilla CSS. However, beyond that, two of the big benefits that SCSS gives you are:
- Nested selectors that eliminate redundancy and keep your code DRY, and
- The ability to use variables for commonly used code (for example, colors). Let’s look at an example below:
Before Sass, vanilla CSS:
You can see in the second Sass example that there’s less repeated code since we’re nesting selectors within their parents.
Sass also lets you define variables for colors, for example, in the code sample above we can set
#EFC6F3 to a variable and call that
$light-pink. We can then access it like so:
If later we decide that we actually want to use
#FFB6C1 for our
$light-pink hex, we only need to change the variable in one place, and the rest of the codebase is updated accordingly, saving us valuable time!
Let me lead with the headline for this section: I purposely wanted to keep this post super simple for those who are just starting out. If you only have one SCSS file, you don’t need to set up folder structures for your Sass, and you certainly don’t need to read philosophical blog posts on different ways to structure you Sass folder structure.
There are many points of view on setting up Sass - different ways to break down functionality, folder structures, partials, etc. When I was just starting out I got bogged down and distracted by it all and it added to my confusion and blocked me from getting up and running quickly. My advice is to start with the bare bones outlined above and build your way up to a full Sass structure.
If/when however, you’re at the point where you’re looking to break down your SCSS into multiple files (and you’ll get there relatively soon after getting up and running), below are some interesting and useful posts on how to structure your Sass project:
- Sass Basics - Sass (official guide)
- How to structure a Sass project - The Sass Way
- Architecture for a Sass Project - Sitepoint (by Hugo Giraudel, a Sass master)
- Sass: Directory Structures That Help You Maintain Your Code - Vanseo Design
- Avoid a Cluttered Mess - Sensible Sass file Structure - Zurb Foundation
I hope you’ve found this post helpful, and feel free to tweet me @christinaent to let me know your thoughts and share any other resources you’ve found interesting so I can add them to this list!