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 is a meta-language on top of CSS that‘s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable 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.
Comments
Nice article. I saw this thing earlier but tought it would be road to hell and it turns out it is one. I won’t be even thinking about trying it.
I really love one-line css, they are so bloody easy to maintain and read, especially if you have a 1680px wide screen. :)
#1 • Ollie wrote this on January 29, 2009 at 3:54 am
Haha, funny. Love the URL especially.
Have to admit I’m still a big SASS fan, but I see your point for sure, especially on the concept of the one-line CSS file, for readability / findability purposes. You can opt to have the .css output file be formatted that way (Sass::Plugin.options[:style] = :compact), but it’s true, that doesn’t help when you’re reading the .sass file.
I’ve found what’s most helpful to me, more than the fact that it’s SASS, is to use a bunch of separate files, to split things out that way. The SASS version of @import can, if you use the .sass extention, just pull the content of one SASS file into another for the .css version, so you still only load one file in the browser
Anyways, cheers ;-)
#2 • Cameron Booth wrote this on January 29, 2009 at 6:21 pm
Cameron, I agree that splitting stuff into separate files helps, but the main problem for me is having to put relating definitions in different parts of the file, which just proves very confusing when you come back to it later.
#3 • Anatoli Papirovski wrote this on January 29, 2009 at 6:22 pm
I should add, that rarely does software “force” you do to anything, but in the case of SASS, yes, they have a suggested approach
#4 • Cameron Booth wrote this on January 29, 2009 at 6:23 pm
I couldn’t disagree more.
I use SASS for an incredibly big site (we currently have 141 sass files). I think most of your gripes come from writing CSS in a particular way. Honestly I have never found it hard to search for the elements I’m working with like you mentioned.
Using variables, mixins and indentation of common attributes means I write CSS faster. It’s also a lot easier to read, which means I get my work done faster.
#5 • Evil Trout wrote this on February 4, 2009 at 8:04 am
I’m sorry, but 141 files is not my idea of maintenance heaven. Again, this is just my experience. If you’re enjoying Sass, good.
#6 • Anatoli Papirovski wrote this on February 4, 2009 at 8:17 am
I totally agree, one line CSS is the bomb. But still why couldn’t you just switch over to CSS once the project got too big to use Sass for?
#7 • Mark wrote this on February 4, 2009 at 10:14 am
Mark, you could… but then why start out with Sass in the first place? :) Somebody put it nicely elsewhere… Sass provides a “low ROI”.
#8 • Anatoli Papirovski wrote this on February 4, 2009 at 10:21 am
Sass has a :line_comments option that will add comments to the generated css file that tell you where the selector was defined. It really makes debugging easier.
#9 • Chris Eppstein wrote this on February 4, 2009 at 1:45 pm
While that makes it easier, in this particular case I’m talking about simply adding/removing/modifying stuff, rather than debugging.
I should also clarify that I’m a huge fan of Haml, just not Sass.
#10 • Anatoli Papirovski wrote this on February 4, 2009 at 2:26 pm
most benefits of sass coul be reached with a template engine on top of css or use of php inside css(if you don’t call php a template engine) , that way you got variables, functions and a true and tested programming language, and don’t have any of the drowbacks you describe here,
do you agree?
whith some more work you can even mess up a lib to produce css faster, but that use case is very limited to the skillset of the user, which is your main point.
tanks
#11 • devsmt wrote this on February 6, 2009 at 3:35 am
Sass easily makes you nest too deep. By convetion we always code our Sass file so that the top level selector is visible in one page of the editor. Even if that means repeating the top level selector. Still after the last cleanup about one year ago things are starting to get messy again. I still like it better than plain css.
#12 • niko wrote this on February 6, 2009 at 2:23 pm
If you’re searching a 5000-line file, you’re doing it wrong. Code should never look like that, and for me the biggest advantage of SASS is I can organize my stylesheet files much more intelligently via SASS’s server-side compilation of @import. This lets me have small, easy to read and maintain files with logical organization - just like all other programming languages.
I’ve written a fairly extensive response to this post back at my blog.
#13 • IdahoEv wrote this on February 11, 2009 at 5:03 pm
Which is funny - I love sass but I’m pretty lukewarm about Haml and am not sure I will use it in future projects after my last two experiences. There are things I like about it, but other things that drive me crazy. (like the excessive hassle of multiple-line code, which conflicts with my predilection for long identifiers and my other predilection for keeping code under 80 chars).
To each their own, I suppose. :-)
#14 • IdahoEv wrote this on February 11, 2009 at 5:08 pm
While I agree that 5000 lines is excessive, there were reasons for it -time constraints for one. With that said, one of the areas was around 1000+ lines of undevidable CSS. BTW I can also spread out the code over multiple files without SASS.
With that said, if there’s anything I learnt in this debate, it’s that perhaps my issues had as much to do with the job I was doing and the time constraints it presented, as they did with the language I was using.
#15 • Anatoli Papirovski wrote this on February 11, 2009 at 5:31 pm
Sorry, the comments are closed at this time.