I’ve decided to write more about web development on my blog, so this is my first post on that topic. It’s about how I converted my CSS from Stylus to Sass. To begin with, I ramble a bit about my experience with preprocessors.

What is a preprocessor?

A preprocessor is basically a tool that allows you to write more “powerful” CSS, by offering functions and variables to make your life easier, and then outputs it as the CSS you already know. Preprocessors have a number of advantages. You can catch syntax errors as you make them. You can minify, outputting your CSS in the smallest file size possible. You can separate meaningful CSS “blocks” into separate files for organisation, then compile it. You can nest CSS rules – which to humans – makes a lot of sense.

Really boring intro about my history with preprocessors.

I first learned about preprocessors in 2010, when I got my first part-time web development job. It later became full-time, and was probably, to date, the job I’ve learned the most at (relatively). I was at a very junior level, knowing nothing about the developments of HTML and CSS. I’d gone as far to validate my code, nest properly, check my website in different browsers, and not just let HTML be its normal forgiving self. But I never got to the point of thinking about structuring CSS and the importance of semantics until then. Preprocessors were completely new to me, and at first I didn’t understand why anyone would want to make their lives easier (because knowing me, I always wanted to make everything hard).

Hello Stylus

At that point I was so in love with vanilla CSS that I didn’t like the idea of using a preprocessor. I liked doing everything manually and writing everything out, character by character. I think it didn’t help that Stylus was the preprocessor I learned about first. Stylus was terribly, terribly forgiving compared to other preprocessors (Sass, LESS):

.blog-article
    padding 1em
    border 1px solid @border-color
    .article-title
        font-size 1.5em
        font-weight bold
    .article-category
        font-size 0.8em

The above is probably an extreme example, but you could forget semicolons after some of your values, and Stylus would throw it in the output for you and forgive you.

You could forget some of the colons between your properties and values, and Stylus would forgive you.

You could even forget some of – heck, all of – your curly braces and Stylus would happily give you a handful of curly fries.

But why?!

Why would you want to forget how to properly write CSS?

Real CSS syntax, with or without a preprocessor

It didn’t occur to me at the time, but I don’t think that Stylus was a good idea at all.

Admittedly, I don’t use a preprocessor in all my personal projects. My fanlistings are a bit out of date and use vanilla CSS – the same goes for Nick’s website, and my portfolio. I only began to use a preprocessor when I built this theme, bermuda. I chose to use Stylus because it was the only preprocessor I knew well at the time. And I chose not to use it everywhere because it quite simply wasn’t needed.

There are several arguments as to why we don’t really need a preprocessor.

But basically (since that is not what I’m talking about right now), you don’t want to forget how to actually write vanilla CSS. I decided to switch over to Sass after I realised that indented gibberish was really not my cup of tea, and that if it ever came to changing my user flow or migrating to other methodologies, CSS without a single bit of discernible syntax was certainly going to suck. As any web developer would and should – I missed writing good, proper CSS.

Cole Peters has written a fantastic little thing about writing real CSS again.

Why I still chose to convert to Sass (and not just write vanilla CSS)

I wholeheartedly agree with a lot of what Miller and Cole have outlined about the problems that can arise from using a preprocessor, but “just because you can, doesn’t mean you should” truly applies in this case.

The benefits of using a preprocessor, for me, include the ability to split my CSS into manageable chunks. I am a big fan of organised, modular code, and using a preprocessor gives me the flexibility to make my code that way.

I’ve done a really shit conversion so far, so I’m still scraping by with inconsistencies in the organisation of my CSS. This is my first time using Sass, so I’ve already learned that there are two types of file extensions – .scss and .sass. I grabbed both of the examples below from the Sass guide.

SCSS (Sassy CSS) – .scss

The new way. It looks pretty much like CSS.

$font-stack:    Helvetica, sans-serif;
$primary-color: #333;

body {
    font: 100% $font-stack;
    color: $primary-color;
}

Sass – .sass

Old. Uses indentation rather than braces.

$font-stack:    Helvetica, sans-serif
$primary-color: #333

body
  font: 100% $font-stack
  color: $primary-color

You can probably guess which one I went for. I went for the first one, because the second one was too much like Stylus. Although I should add that only the colon seems to be necessary in Sass. If you forget the colon, you get thrown an error. If you actually put in a semicolon, you get thrown an error too.

Oh shit, I minified

I can’t even remember if I used to minify my CSS, but I am pretty sure I did. The problem was, Stylus did such a shit job of doing it, it messed up my media queries and broke my site. I ended up using another simple conversion tool, but then gave up and left my CSS unminified.

But, but, Sass does it now, and does it perfectly!

I love this command.

sass -t compressed --sourcemap=none style.sass ../style.min.css

(I haven’t quite figured out whether I need the source mapping or not, but I believe I can go without.)

My CSS, unminified, is 23KB, and minified, it is 19KB. :)

Conclusion: A work in progress

After some time working on it, I ran git diff to check that my original CSS was not destroyed. And it’s up and running on my blog now, and if it looks fine, then hooray. :D

From now on, you can see how I am going with this on GitHub. However, I haven’t quite gotten my CSS how I want.

The first issue is that I wanted a quick, MVP solution to initiate the conversion, and I had to write in all my CSS syntax – curly braces, colons and semicolons. I decided to do a half-assed job and only did this where it was easiest. On the others, I only put the bare minimum – a colon – and used the .sass extension on those. As the next step, I plan to get everything consistent.

My other issue is that my CSS lacks modularity. I built it with SMACSS methodology, but as time passed, I began to think of even more ways to make it simple and modular.

Since I am planning a redesign for my blog, it might happen in conjunction with improving my CSS architecture.

I look forward to writing more posts like these, so I hope this wasn’t too dull. ^_^