After singing SASS’s praises on Twitter for around 10 weeks now, I figured it was about time I wrote something substantial to properly explain why I like CSS preprocessors so much.
Firstly, you’ll find no heavy code here; it’s more of a ‘what and how’ than a ‘why’ kind of article. Secondly, most of what I’ve covered can be done in either LESS or SASS, just look for the relevant links.
Consider this the include(); of CSS. I know, a bit of a crude description, but it’s a pretty apt comparison.
Just like plain ol’ CSS, preprocessors have
@import, but if they’re LESS or SASS files then they are processed differently. Preprocessors compile to produce flat CSS files, but unlike traditional CSS, when they see an
@import, it grabs the code from the partial file and puts it in the master file. I admit, you could use
@import in traditional CSS, but with every file comes 1 HTTP request, you’d be sacrificing page load for the sake of organisation.
The main benefit is, quite obviously, organisation. CSS files can get long pretty fast, and as noble as it is to traverse up and down a massive CSS file to add code “in the right place”, I just found it downright laborious.
@import in preprocessors, you can abstract entire chunks of code to separate, logically named files. Here’s a few typical examples:
- Reset / Normalise (required, but can be bulky)
@font-face(gets lengthy when using variants)
- 3rd party libraries (sliders / carousels)
- Mixins (e.g. CSS3 helpers, aiding with vendor prefixes)
- Variables (e.g. Colour Schema)
Familiar with PHP or JS? Of course you are!
Again, nothing new here…preprocessors are just implementing a pretty basic programming feature that is – as of yet – not part of CSS. Just create a variable, set it a value and call it throughout your CSS…simple.
The main benefits with preprocessor variables is consistency, less reliance on your memory and less copy & pasting. No longer do you have to waste your Rain Man talents on remembering hexadecimals or sprite URLs; just give ‘em a name and be done with them!
Names like forestGreen, bloodRed and salmonPink are much easier…right?
Extend / Mixin
Although they differ in how they function, mixin and extend both exist for the sole purpose of stopping you repeating yourself.
Extends are for when you want to use the code of another selector, in its entirety, with those exact properties and values.
Mixins are when you have a chunk of code that repeats itself through the project, it uses the same properties, but you want to use different values. Like a function in PHP / JS, your mixin has parameters that are then used in math, conditional logic and/or straight outputting. You write your code once, then use it again and again.
Whilst working with SASS, I’ve been using mixins to write my CSS3 vendor prefixes for me and extends to aide my Pragmatic Font Sizing approach.
[Nested] Media Queries
If you’re building a responsive site (mobile-first) with traditional CSS, you’d likely have blocks of
@media that progressively get bigger..like 320andUp. When I started doing RWD, I did too…but it just feel a little ‘broken’. To me, grouping together changes to elements based on viewport width seems a little counter-intuitive, a little fragmented.
For me, being able to see how one element adapts as the viewport grows is much easier to work with, and that’s exactly what preprocessors allow you to do; they allow you to nest
@media inside a selector.
You don’t need preprocessors to minify CSS, there are plenty of tools available, I just really like the way that preprocessors – like LESS and SASS – approach it.
The compiling nature of preprocessors mean that your precious master file retains its structure and commenting, whilst the real minification happens in a separate file. And because compiles happen on every save, you can have a minified file that’s always up-to-date.
With tools like CodeKit, you can switch between compression type and output path in the blink of an eye; once a site is live, BAM…CSS is minified for production usage.
There are some developers who have dismissed using preprocessors as “overkill”, but my response would be to reserve judgement until you’ve actually tried one of them. I believe that – regardless of your ability, approach or project size – they’ll be some aspect of preprocessors you’ll like. Just set aside an hour or so, get one of them set up and have a play; trialling stuff is the only way we can determine what will help (or hinder) us.
I think it’s worth noting that the beauty of these preprocessors is the “pre” bit; it all happens before, it produces the same end product. It doesn’t carry the guilt of say, loading jQuery for the sake of using
.addClass() once; you can use as little or as much as you want and it’ll have zero overhead on your project. I myself started using SASS just for it’s ability to compile
@import, the other features just naturally crept in.
Just give it a try, I think it might surprise you.