Sass is one of those subjects that I generally know what it is, but have never actually worked with before. I know it’s supposed to provide some pretty nice quality of life items when working with css for your site, but that’s where my knowledge stopped. Today that changes! Let’s get to work.
A bit of a tangent before I get into what I actually learned about sass today; when I first started out working on web related technology, I heavily relied on a youtube channel called Traversy Media. When I first started following it was a relatively small channel that has blown up over the last 4 months or so. Brad, the owner, is a super great dude. He puts a lot of effort into putting out great content, both free and paid, to help people get their feet wet with different topics. I’ve personally purchased a few of his different Udemy courses and they’ve all been pretty great.
Today’s topic was brought on by a new set of videos he put up the other day covering using sass to build kind of a portfolio website. It’s a multi part video series, and this post will be covering items I learned from the first video, linked below:
What is sass?
Unfortunately, this question was completely ignored in the video. Not sure why, but that’s a bit of a bummer. Oh well, off to google.
SASS stands for Syntactically Awesome Stylesheets, and is a preprocessor for CSS.
At its core, it allows for a better workflow when handling your stylings within a project. It opens up the ability for defining variables or functions and makes things reusable. Nice! I’ve never really been a big fan of working with CSS as I know I hate typing the same thing over and over again, so having the ability to declare properties in one spot and reuse it as need sounds fantastic to me.
Sass itself does not run in the bowser. It must first be compiled down into the CSS you’re used to working with before importing it into your website.
This means that we’ll need to get a compiler setup to handle our workflow.
The Basic Workflow
The work flow of sass in a project is pretty simple. We start by making a
scss folder in our project directory. This is where all of our scss files are going to exist. Evidently scss files have the ability to reference other scss files, so we’ll want to keep them all bundled together.
All of our projects css will live in these scss files. Any time we need to make a change, we’ll come to these files, update the scss, and then run the compiler. The compiler will take all the scss files, convert them to useable css, and then place the css files into our project. The page can then be loaded
There are ways to setup the compiler so that it will run anytime that it sees a file changed, but that’s pretty much only for local development. You’d need to build that into your actual deployment pipeline (not sure what that looks like yet).
Setting up a compiler
The video recommended using
node-sass as the sass compiler for this project. Evidently it’s pretty zippy, and it’s just a quick node package install away from being up and running. To install, simply run:
npm install --save node-sass
If you want to set up node to build the css for you automatically after every save, you can create a new command in your
"compile-sass": "node-sass -w scss/ -o public/css --recursive"
Or you can can run the command on its own from the command line.
That’s it for today. At least I’ve got a better idea of what sass is now and how it gets converted over into css in the final project. Tomorrow I’ll probably continue with this project (maybe wrap it up this weekend).