CSS Adventures: Converting from Stylus to Sass

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. 😄

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. 😊

Leave a Comment

Comments on this post

Good work Georgie! Nice bit of technical writing that is different and in your own voice and no its not too dull. Nice work on the CSS, I’m looking forward to seeing whats next! 😄

Thank you! 🙂 I hope other people can find some interest in what I am passionate about. I look forward to sharing much more about web dev, whether it’s opinions, discoveries, random thoughts or something else entirely. 😄

I’ve been thinking about trying out SASS for some time now. I’ve never used CSS pre-processors but I can definitely see now how useful they could be, and now I know that I won’t have to unlearn what I’ve learned about CSS!

I obviously like reading about this kind of thing so I’m looking forward to more web development posts from you! 😄

I’m glad you enjoyed reading it – I’m not surprised that you did! 😉 It’s relatively easy to pick up the ins and outs of most preprocessors (the ones I have used anyway). Pretty much all the time, they will still parse CSS where you have written it the conventional way – so yep, definitely no need to unlearn anything. 😄

I liked reading this. I can see that it would be handy, especially because there are more and more ‘required’ styles now, and the css could grow so big it would be a monster.

I still like to write it out (as best I can). But I also use Foundation lately, so I kind of just have my custom styles and mods that I add too it. 😆

It’s definitely good from an organisational point of view. I think it is almost necessary for large websites. Where I used to work, we had one massive stylesheet that was just manually added to over time, at the end of the file, making it a giant mess. No one knew where bits and pieces were.

I have not used Foundation but I remember wanting to the first time I saw it. It’s very pretty compared to Bootstrap – most companies choose one or the other. Frameworks can help a lot, but I personally love to build things from scratch.

this is a helpful post 🙂

i’ve been telling myself to learn about sass and less and even master the bootstrap framework but yeah, i’ll have to search my developer persona so i can focus and learn them, else i’ll just scheme through and strain my brain because i can’t digest the technicality.

i do enjoy reading this though. i think you’re a great web developer and i sometimes look out to your design so writing a post of this category is a plus 😄 sigh, i need to polish my “web languages” ….there’s so much to learn and all i want to do is just rest and do nothing.

As I’m making my way to more advanced webdev projects (read: switching from Textpattern to WordPress), I’ve been introduced to Sass. Lo and behold, as I was browsing your blog, I came across this article!

I love vanilla CSS. I love a good, clean, vanilla-code webpage with the bare necessities. The unfortunate thing about it is how time-consuming it can be to change it. If it’s static, then I tend to lean toward straight vanilla–like my portfolio, which I really do need to update. But with the dynamic aspect of a blog, I need to bring in more advanced codes for sure. When I was looking through Sass, it just made sense! There was more syntax to it than just the CSS form for proper code! There was a flow to it! The way I see it, there are styles inside a stylesheet, like paragraph styles in InDesign or a word processor. It’s beautiful–even if I’ve spent less than a day looking into it and trying to figure it out. 😛

I love vanilla CSS but it is very nice to have a preprocessor that can provide a few extra features to make our workflows better. I think the best part about using one – particularly for people like us who love vanilla CSS – is the flexibility we have to modularise our CSS and split it into different files to make development easier. 😄