Preprocessor Myths

There’s lots of grumbling, bullshit and opinion pieces focussed on the evils, joys and complexity of CSS pre–processors lately. Whilst I’m fully aware I’m adding to the noise, I’m writing this anyway because fuck you why not? Please, if you’re new to CSS, don’t read this. Just learn CSS first and get good at it.

This is mostly going to focus on Sass, because I want to. Feel free to replace it with whatever crazy tool you use and love and evangelise to the point where your friends fucking hate you and your stepdad purposefully forgets to buy you Transform–A–Snack when he goes shopping.

For the majority of these you can also replace the word ‘myth’ with ‘opinion I have seen perpetuated that I disagree with based on my own familiarities with something towards which I am biased’ but that’s not very snappy and certainly won’t be getting me on the Smashing Mag newsletter.

Myth 1: They are new

Sass was introduced in 2007. That’s nearly a decade. It’s increasing in popularity, but it’s not some new, futuristic technology. It’s robust and has seen lots of iterations. If you’re writing an article on just how perfect Vanilla CSS is and how you’re gonna beat Sass up after school, consider going with a different angle to ‘this new–fangled CSS preprocessor stuff’ because you sound like a fucking dinosaur and probably still think XML is nice.

Myth 2: They make your code bloated

You make your code bloated. By writing bloated code. By all means, be as shit at writing Sass as you are at writing CSS, but remember you’re using a tool and you should probably fucking learn it. If you’re nesting selectors deeper than my face into my hands every time I read your blog, you’re probably going to have some ugly code. If you’re extending classes left, right and centre; you’re probably going to have some ugly code.

Sass reads, for the most part, like normal CSS. If you lack the cognitive nous to at least predict the complexity of your compiled CSS based on the structure of your Sass, there’s a good chance you’re going to end up with bad CSS whether you write it vanilla, use a preprocessor, or sacrifice your dog to Fenrir.

Finally, I’d recommend anyone who’s about to jump on the ‘performance’ bandwagon to consider the size of their files after gzipping. You’ll be surprised just how little weight the code bloat argument holds, even if you go wild with some of the shitter Sass practices.

Myth 3: They’re Ruining CSS

CSS is ruining CSS. Because it’s shit.

CSS is missing lots and lots of shit that developers have been crying out for: variables, operations, functions and an actual decent way to split your code into multiple fucking files to name a few. The sad fact is, independent developers can add features to their tools faster than it takes the cyclopean Working Group to read through their chain email (sorry, friends in the WG, I still love you). This means they’ll always outpace CSS when it comes to bringing cutting edge, desirable features to front–end developers’ workflows.

While there’s logic behind the idea that things like Sass are turning CSS into something it isn’t (a programming language), I think, conversely, CSS is remaining something it shouldn’t be.

Myth 4: I could come up with more than 3 myths

I’ve just proof-read everything above and I feel so dirty that I’m not even going to continue because I’ve legit just wrote a fucking opinionated listicle about Sass.

I’ll still publish this, I bet, because it’s 1am and I’m an actual piss wizard. People will shout at me on Twitter. Everyone who hates me will hate me more. I’m never getting that fucking pack of Transform–A–Snack.

If you got this far without blocking me on Twitter or throwing your fist through your screen, then commendations friend.

To Summarise

Sass is old. You’re shit at coding. CSS is bad.

I’m off to run a bath and wank away the shame of what I’ve just became. Hugs.

If you have any questions, comments, insults, haikus (seriously, I love haikus) or insults, lob them at me on Twitter.