Sass, the bull in a china shop

In theory, Sass is great. But when applied in real life situations — large-scale projects with multiple developers — it fails spectacularly. Read on to find out why.

I’ll begin with some information about Sass, which by default comes bundled with Haml. In fact, I’ll let Sass speak for itself:

SASS gives visual coders a simple and yet elegant method to write CSS and implement its nuances making life much easier with multiple interlinked stylesheets.

Who wouldn’t want that? I mean, honestly, is there anyone who wouldn’t want “simpler, more elegant syntax” coupled with “various features […] for creating manageable stylesheets.” Sounds awesome, doesn’t it? And that’s exactly what I thought until I spent six months maintaining a web application utilizing Sass.

Unfortunately, the Sass syntax is simply broken. It only makes sense if you’re working with a really basic website that isn’t updated very often. I think we can all agree that most Ruby on Rails programmers don’t fall into this category.

I’m looking for selectors, not properties

The first issue with maintaining Sass is simple and does not cause much of a problem on its own. After all, even CSS can be formatted in the same way.

I’m talking about the fact that Sass chooses to use new lines for every property. This leads to a very long file (thousands of lines). While this makes sense in a real programming language such as C, Java, or even Javascript, it doesn’t make sense in CSS. CSS is based around selectors; they are the main building blocks and the main things you’re likely to look for when editing a stylesheet. Once you find the correct line with the correct selector, you can easily find the property within the same line. Sometimes this is called Single-line CSS.

On its own, this is a small problem. However, it becomes a much bigger problem once you combine it with another big part of Sass — grouping styles together and indenting them to indicate parent-child relationships.

Group everything together and…

It’s a great idea, that is, until you’re trying to meaningfully organize your Sass file and later find stuff. Why?

Because the more specific your selector is, the more time it takes to parse it. Reason being, rendering engines start parsing from your key selector (the last selector). Given the example of #wrapper p or #wrapper > div, the parser would begin with p, div and work outwards, verifying that each selector matches.

Now, Sass wants you to nest your selectors, supposedly making your code easier to maintain and more logical. The unfortunate consequence is that the code can turn into #wrapper #content #article, rather than the simple #article, which would suffice.

The only way to get around this issue is to start declaring all your selectors separately; unfortunately, at this point you’ve lost most of the benefits associated with Sass. But the trouble doesn’t end there.

The cascade

The beautiful thing about CSS is it’s cascade, where each rule has an assigned priority and thus you can overwrite less specific rules with more specific ones. But this is where Sass really breaks.

Imagine that you have a #wrapper and #main selectors defined on their own. Now you declare a definition for #article, nested under #main. In a couple of weeks, it turns out you need to declare a rule with higher priority for situations where div#main is nested in div#wrapper. Let’s say that for various reasons you are not able to use !important override to take care of this.

Following the Sass design, you go back to #wrapper and nest #main under it, then you add a new definition for #article. In the next few weeks your code keeps growing. Now you’re looking to modify the CSS again. You start looking for the #article definition, but it turns out, instead of being with all the other #article code, it’s stranded up 500 lines, nested under #wrapper.

In that particular case I could’ve used search, it’s a fairly specific selector. But imagine that the stylesheet is 5000-lines long and you’re looking for p selector, rather than #article. In classic CSS you could just search for #main p, but in Sass they are miles apart. Swell, isn’t it?

Finally

Sadly, this isn’t the worst part of Sass. Sure, you have it difficult with your extensive Sass stylesheet. Now imagine that your team gets a new front-end developer. Good luck to her, she’ll have a wonderful time figuring out where everything is in the Sass stylesheet.

With CSS you could organize everything meaningfully, not based on what the software forces you to do. Yes, you could technically come up with a way to have your Sass is organized and tidy, but it would take many days and a lot of careful planning. You would also be required to do the same before adding any completely new modules to your site.

Are you part of a start-up? All the more reason to avoid Sass. Start-ups are naturally fast-paced and you’ll never have a chance to fully plan out your Sass stylesheets so that they’re clearly organized.

Trust me! First I was the guy who had to deal with an extensive Sass stylesheet that I didn’t write. Later I was the guy who coded one from scratch, and maintained it — for six months.

I never enjoyed CSS less, not even when debugging IE6.

 

Leave a Reply

Your email address will not be published. Required fields are marked *