Some Preprocessed Thoughts on Sass
This is a bit risky. It’s only my second post but I’m going to touch on a topic that divides developers like religion – preprocessors. There are a few things I would have loved to have known when I fist dived into using them, so I though I’d share my brain dump on the subject.
So, while I exclusively discuss Sass/SCSS here (because it’s the one I use) the concepts very much translate to the likes of Less, Stylus, or others.
My humble beginnings with Sass
The hardest thing I found when working my way around this new way of writing CSS was the out of the box explanation of what it is just wasn’t working for me. Here’s my analogy on it:
Sass is like the brown sugar you sprinkle on your cereal. It’s not really necessary because there’s probably already enough sugar in that cereal to make any one of Nigella Lawson’s recipes twice over, but it adds a layer of goodness that only other people who also sprinkle sugar on their cereal can ever understand.
CSS is that cereal and it makes up the bulk of your breakfast. Sass is the brown sugar. You can choose to sprinkle as much or as little on as you like, but either way it makes the final product so much better.
In all seriousness, here’s a rundown on the primary buzzwords with the big names in preprocessing:
- Sass – the primary name used but actually the older syntax (see below). Sass allows you to ditch the curly braces and use whitespace to define structure. It keeps things clean, but moves you further away from writing traditional CSS. The file is named with the extension .sass.
- Scss – What I write (even through I call it Sass). This form of Sass is written exactly like CSS is, curly braces and all. The file is named with the extension .scss.
- Compass – This is a framework (not a preprocessor) that builds on top of Sass. Compass contains a lot of goodies that would take ages to code by hand, but instead can be easily tied into your Sass project. This includes things like grid frameworks, button sets, vendor prefixing and all other kind of awesomeness. The best explanation you’ll find is this one from Chris Eppstein.
- Less – Another popular preprocessor and written very similar to SCSS except that is uses a slightly different way to declare things and has a slightly different feature set (that’s a whole other post). As an example, a variable in Sass is
$variablewhile in Less it’s
The ‘why’ of my Sass addiction
There’s a real world example of why I started using Sass. I have a hard time remembering HEX values. I usually employ one of three tactics – I will write the hex values at the top of my CSS file and spend the majority of my coding time scrolling up then back down, I will wear the names off the CMD and TAB keys on my keyboard from switching back and fourth between Photoshop and my code editor, or I will scribbble them on a stray piece of paper which will inevitably end up being obscured by coffee stains. That’s where Sass variables stepped in. Now at the top of my Sass sheet I can declare styles like
$primary: #61c42 and then just apply
$primary as the colour throughout my stylesheet.
It’s important to remember that you do not need to use every single feature the technology offers in order to dignify its existence. To be honest I would still be using Sass even if variables was the only feature it had.
Tools of the trade
When sass was just released it was something that could only be installed through some command line magic. Like any new coding kid on the block, the app-making masterminds (we love you, even if you have an unhealthy obsession with to-do apps and plastering everything with iOS linen) set out to make it more accessible to everyone and in stepped apps like Codekit and Live Reload.
These tools are preprocessors that output style.css files for you to put up on your server. If you’ve taken on other languages you’ll find they can also handle the likes of HAML or CoffeeScript. There are of course other options like having the Sass compile on the server or client-side, but I won’t discuss these here. For small scale projects, preprocessing prior to publishing is probably a good habit anyway.
For reading up on the development of Sass, which for the record is anything but stagnant:
There are also some other great articles I have found throughout my time on the topic:
- CSS-Tricks Musings on Preprocessing
- Net.tutsplus Sass vs Stylus Preprocessor shootout
- Net.tutsplus Mastering Sass
- Smashing Magazine Introduction to Less and comparison to Sass
The inevitable disagreement rages
When I first started looking into Sass (and SCSS) I noticed that when anyone raises the topic in a blog post, the inevitable first comment always relates to the workflow efficiency vs bad code debate. One comment that best sums up my view on on this debate is from Roy Tomeij in his post on The Sass Way:
“Sass doesn’t create bad code, bad coders do.”
The more I dive in to Sass and learn its strengths and weaknesses I view this comment slightly differently than I originally did but the reality of it is that Sass will create whatever kind of code you set it up to, whether that be good or bad. What the creators of Sass (and Less) have done is create an expansive tool that one can use as strategically or as carelessly as they please.
Nicolas Gallagher proved this nicely in an experiment he ran on his blog:
When Twitter Bootstrap first came out, I rewrote the compiled CSS to better reflect how I would author it by hand and to compare the file sizes. After minifying both files, the hand-crafted CSS was about 10% smaller than the pre-processor output. But when both files were also gzipped, the pre-processor output was about 5% smaller than the hand-crafted CSS.
It’s all about moderation
- Sass will only output what it needs to. You can set up a million different mixins but if you only call one of them in your CSS then only one will be output.
- Nesting is a feature of Sass that is both a blessing and a curse. Nonetheless, it’s a feature, not a requirement. If you nest 5 levels deep then of course you’re going to end up with selectors like
#main header nav ul li a.selected:hover. The trick is to use it sensibly and where appropriate. In my case, I will almost always use it to define things like :hover because it’s logical, however I won’t nest every element inside the wrapper element because it is just not necessary to have #wrapper at the beginning of every selector.
- Media bubbling has a ways to go. I can envisage how it will become a wonderful tool when identical media queries will have their declarations grouped inside one query but at the moment the same media queries are just repeated as used. I don’t view this as a reason to not use Sass because the major advantage here is still the ability to add the media queries directly into the selector – allowing you to create a modular Sass structure. A smart coder would just use them sparingly or write them out like they normally would in the Sass document, no harm no foul.
What Sass is not
- Sass is not a replacement for CSS. When you write Sass, you’re still writing CSS the same way WordPress code doesn’t replace traditional PHP. Instead, it builds upon CSS by allowing you to increase efficiency and perform actions that are not necessarily supported (or ever will be supported) by spec’d CSS.
- Sass does not ‘create’ bloated code. Sass only creates what you tell Sass to create. If you’re careful and sparing with its features, it will create a smaller CSS stylesheet then your hand-crafted version. True story.
- Is not a new coding language to learn. On a basic level Sass contains only a handful of concepts – variables, mixins, media-bubbling, extend, etc but the options contained within these are endless. Sass is something you learn in an afternoon and spend the rest of your career building upon and optimising.
Why you should always compress your preprocessor output
There are four reasons I always recommend you output your CSS as compressed which all decent preprocessor apps will do for you:
- It’s less likely your CSS will get ripped off when it is perfectly readable by a computer but not by humans
- Your CSS file will be smaller. Regardless of how much code is in there, that whitespace adds up!
- If you want to make a small tweak you will need to do it in the Sass file and re-process it (yes, this is an advantage). This keeps your Sass file as up to date as your css one.
- The heavy development of web inspector tools means there’s no need to be able to actually read the view source code nowa-days.
That’s all I can think of for now. So on that note – Viva la Sass.Tell the World