My Opinion of SASS and LESS for CSS

I’ve been working with CSS for more than a decade and I know all too well the problem areas, primarily in browser support and development difficulties. Tools like Firebug and similar page inspectors have changed how I debug problems but as developers, we’re always seeking the more efficient route.

On paper, the ideas behind Sass and Less seem amazing. Shorten css development by using variables (for colors, etc), reduce the amount of written syntax by calling functions once, that when compiled, produce all necessary vendor prefix equivalents, and so on. By themselves, those were enough to convince me to try it.

I tried Less first, which is mainly different by the fact that it uses javascript to compile the real css. For those unwilling to add another script and process time to the client-side there are server-side solutions as well, and then there’s Sass. Sass has essentially the same features but is compiled on the server by Ruby gems.

However, when I began using these in already-live projects I discovered how painful they are. Here is a quick rundown of everything I’ve discovered about using these technologies versus hand-written CSS.

The Environment

Right out the gate, using Sass was a pain because I had absolutely no development environment for it. I had to install ruby, as well as the gems for compiling it. Firebug needs an additional plugin (and the gems need additional configuration) so that it will point you the Sass file and not the compiled css file. All of my editors/IDEs needed special plugins in order to recognize the syntax (for coloring, etc).

Now this is all install-once-and-you’re-set stuff but it still throws several additional steps into the mix when I move to new machines, etc.

Every day of work I need to ask the compiler to watch the project for changes. When I forget to do this, I get frustrated wondering where my css changes are.

The Nesting Danger

One of the benefits of sass/less is the ability to nest selectors. The sass could look like:

body {
  /* ... styles ... */
  header {
    /* ... styles ... */
    nav {
      /* ... styles ... */
    }
  }
}

When compiled, the selector for nav becomes:

body header nav {  }

The issue is that while attracting you with a nicer layout in the raw css file, it’s compelling you to build unnecessarily complex selectors. Although there are times when you need to specify the hierarchy, it’s not every time. In one project I’ve taken over, almost everything is nested this way.

It’s a performance hit to the browser because every chain becomes longer and requires a more specific application of the styles. The bigger issue is that it becomes an absolute nightmare trying to override styles. When I’m attempting to override a base style for a larger screen size I must repeat the entire selector because CSS requires that specificity.

So I’ve wound up writing selectors that look like the following:

body #main ul li a { float: none }

It creates a lot more hassle about figuring out what the exact selector needs to be, debugging it when it’s not working, and sorting through the clutter this adds.

Commit Spam

When using version control it’s very easy to suddenly see a huge amount of commit spam from the compiled css. You can bypass this by compiling the css on deployment but that’s a bit more effort. If you have development configurations in place, sass will leave a lot of comments in the compiled css referencing the original location of the sass-version. These change with every compile and if you have a thousand-line-long css files, your commit diffs will be absolutely huge, even for a one-line change.

In fact reviewing said commits will be impossible because you can’t figure out what changed in all of that mess. In order to avoid that, you need to be sure that you never commit compiled code with any development/debug info left in.

When you’re working by yourself I see more of a benefit to using these technologies but when you’re working with a team, you’re not the only one who has to do these steps. It becomes the entire team.

Conclusion

I’m ready for you tell me why I’m wrong. But in the end I have to ask if all of this work is really worth not having to write extra vendor prefixes (which we all copy/pasted anyway) and having to refer back to your notes for each rgb/hsl/hex color code? It seems like that’s a lot easier to do to me.

No related posts.

8 Comments »

  1. Yes, you are right that when using version control it’s very easy to suddenly see a huge amount of commit spam from the compiled css.

    Comment by Dot Net Developers — September 28, 2011 @ 4:22 am

  2. [...] the original post: My Opinion of SASS and LESS for CSS | Botsko.net – Web … Share and [...]

    Pingback by xhtml css templates – My Opinion of SASS and LESS for CSS | Botsko.net – Web … | XHTML CSS – Style sheet and html programming tutorial and guides — September 29, 2011 @ 2:46 am

  3. I think many of the problems you mention have to do with css not having these features natively (the environment problem, commit spam and other stuff like debugging).
    It would be nice to see improvements like this natively in css and get these solved.

    About the nesting issue, the problem is bad developers. You are not supposed to replicate the html nesting with selectors. You should never use nesting if you were not going to chain selectors in plain css to begin with.

    You should only header{nav{}} if you wanted to style navs inside headers. If you wanted to style navs anywhere they show up, you should just nav{}. Just like you always did in plain css.

    I think mixins are a good way of avoiding multiple classes in html elements (I think they should be avoided). Currently the only way to do this is using comma separated selectors to reuse styles. But they have some problems, like not beign able to reuse styles defined in other stylesheets and making it harder to track what styles a particular class is assigned.

    Comment by Jens — October 27, 2011 @ 7:03 pm

  4. I find it a bit one-sided that you talk about the problems of having to install Ruby, Gems etc.

    You mentioned you tried LESS first but neglected to point out that the effort required there amounts to little more than an additional script tag or line of PHP. (You could also just use Simpless and be done).

    I’d also point out that you don’t have to suffer from ‘commit spam’ with SASS and it’s not even an issue with LESS.

    Further I agree with Jens in the comment regarding selector length being in the hands of the programmer. Personally I tend to find the CSS generated is on par with the longhand CSS I used to create.

    As well as making me more efficient, and giving some ridiculous flexibility I also think preprocessors help people produce better CSS as it becomes more comfortable to add many of CSS3′s more advanced features.

    Lastly have a look at flawless to see how LESS can do things like cut down on presentation markup for grids:
    https://github.com/DominikGuzei/flawless.css

    Convinced yet?

    Comment by 32bit — February 8, 2012 @ 3:10 am

  5. A few weeks ago I spent a couple of hours learning LESS at work. I was enticed by the ability to use variables and to nest selectors. I only tried the JavaScript version and was not impressed by the quick 1-2 seconds that your website appears without CSS (before the LESS script compiles the *.less files into CSS) – although this would obviously not be a problem with the server side version. Honestly, thought, it’s just easier to write and maintain plain CSS, especially when it comes to overriding styles as you pointed out. I don’t want to waste time compiling my CSS just so I can troubleshoot specificity. The situation would be different if my whole team was eager to learn, implement, and install LESS system-wide, but it’s just not the case. I ended up reverting to the non-LESS setup after a few hours of testing. I still think LESS and SASS are great projects and hope that one day projects like these will lead to a more sophisticated and less verbose CSS or CSS replacement. I might even give them another shot one day down the road. It’s just not realistic for my situation.

    Comment by Mike Moore — April 9, 2012 @ 1:31 pm

  6. I just started investigating LESS yesterday and i find it very helpful but my main problem is i cannot preview my page in dreamweaver like the plain CSS i can see that my text style is change for example when i update it in CSS, in LESS i need to go to my browser and hit refresh to see the changes.

    I hope this will improve and adopt by the plain CSS in the future.

    Comment by JovenShadow — April 18, 2012 @ 12:17 am

  7. You’re right that the devs are probably piling up selectors on too many projects, but that’s not an inherent issue, I suppose. Just, as you say, tempting.

    I’d be more inclined to use pre-processors if we had better Windows apps. Until I get one with a folder-wide search, live reload, and a file combiner, I can’t see the point of the rest of the pre-processing. If I need to do a global replace on a number, it only takes a second.

    Comment by Lore — February 2, 2013 @ 2:43 am

  8. Edit: I also want a Windows app that doesn’t require an entire Ruby install. i just think it’s ridiculous to install an entire development environment (when I’m already running another), just to do some text editing. Not going to do it.

    Comment by Lore — February 2, 2013 @ 2:46 am

RSS feed for comments on this post. TrackBack URL

Leave a comment