Increasingly, I’ve found my needs from Sass are quite specific and many of the features and integrations I have struggled to get working have not proven as useful as I thought they would.
Let me be clear. This doesn’t mean I believe these features aren’t useful in general; just not in my own circumstance and workflow.

Look I’m in a box – this is because I want say I’m incredibly thankful to all the people who have contributed to Sass and related projects. I certainly don’t intend to appear ungrateful for their efforts. I love using Sass. These are merely my whims! Hopefully that’s ingratiated any Sass contributors who may stumble upon this post to not be offended.

Source Maps

I spent many hours getting source maps working. Now they do and I find I rarely actually make use of them. As I’m authoring the Sass/CSS I have a pretty good idea where to look for a style or property. Even when I have lots of partials in play.
I’m sure Source Maps can prove very useful if you’re debugging someone else’s code or when troubleshooting a poorly organised project but I just don’t get much mileage from them. I try and keep all the specificity of my CSS very ‘flat’. This means that if I’ve been a good boy, a selector should only be declared once across a project. Therefore, at worst, I’d just copy the selector name in question from the dev tools window and search in Sublime across all my sass files. Perhaps if saving back to source files and recompiling Sass was much quicker (more of which shortly) the facility to edit directly in the dev tools would be more useful but for now I can live without it.

Compass and its CSS3 mixins

At present, I’m using an all Grunt-based workflow. In it, I’m finding Autoprefixer very useful. It allows you to write nothing but W3C spec CSS in your Sass/CSS files and when required, it automatically adds relevant prefixes as and when needed. There’s a great write-up on Chris Coyier’s site for more info if you’re interested and haven’t used it so I won’t expand upon it here.
At present Autoprefixer doesn’t work happily alongside Source Maps. However, as I’ve already pointed out, I can live without source maps so I’m happy to forgo them for the convenience of not having to write anything other than W3C compliant code in my Sass and have Autoprefixer do my vendor prefixing.

The upshot of this is that unless I’m doing something sprite or data-uri intensive (in which case Compass totally earns its place) I can live without Compass. One of the main reasons I used to use it was for the convenience of auto-prefixing experimental CSS features. At present, I’m finding Autoprefixer more effective and faster for that. So Compass and up-to-date mixins is another thing I actually don’t need any more. As such it is one more dependency I can remove from my tool chain.

New Sass 3.3 features

On David Walsh’s site, Hugo Giraudel has a written a great post about upcoming Sass 3.3 features. For me, most of those features are not things I need; they won’t make much difference to the way I use Sass day-in and day-out (I rarely need to write @functions or @mixins, let alone plugins). Needing advanced operations for lists in CSS for example, just isn’t a problem I face very often.

For a video going through many of the new features, Sass core team member, Chris Eppstein gives a run down at the

Perhaps the only one of those features that piques my interest is the name spacing capability for modules. That is something I would use everyday. To exemplify, if I’m making a component/module for a widget I might name-space it like this:

.widget-wrapper {}
.widget-name {}
.widget-info {}

Sass 3.3 will facilitate this in a more self-contained fashion by allowing this to be written in Sass like this:

.widget {
  @at-root {
    .#{&}-wrapper { ... }
    .#{&}-name { ... }
    .#{&}-info   { ... }

Not a seismic change but I can see some use-cases for that in my own work.

So that’s enough about what I thought I needed and don’t. What would I actually like to see?

What I actually want from Sass

I’ve found that for 95% plus of what I do, I actually don’t need much from Sass that it doesn’t already give me. Here’s what would provide the cherry on the cake:

Improved partial importing

On large projects I tend to create partials for everything. One for text-styles, one for placeholders, one for every new feature branch I work on. It’s easy for me to get to 20+ partials in a Sass project. Writing the @import directive for each partial I want to import is a chore and it’s a brittle practice when you are included lots of modular partials in a project. It’s easy to add a partial and forget to @import it.

Thankfully there is a Sass plugin ‘Sass globbing’ that lets you import a bunch of partials in one go. I’ve covered how to install and use Sass globbing in ‘Sass and Compass for Designers‘ and noted there:

If the order of imports is important, using Sass globbing may not be a good idea. For example, ordinarily normalize or reset styles are at the beginning of a style sheet. With Sass globbing it’s likely they will be imported near the end. Believe me when I tell you that this won’t make for a happy day in the office.

However, as long as you understand that Sass globbing is a big help. I typically have a few order dependent imports and then all my modular imports as one (they contain all the low specificity rules where order is unimportant). So my main styles.scss might look something like this:

@import "base";
@import "variables";
@import "mixins";
@import "placeholders";
@import "_partials/modules/*";

Sadly, as Sass globbing is a Ruby based requirement, it’s not possible at present to use Sass globbing with libsass (more on libsass in a moment so hold that thought).

There’s been lots of talk on the Sass project about a new way to import/merge partials files together. At present this is a feature slated for Sass 4.0. Can’t come soon enough for me, and if they could improve the speed of imports so much the better!

Compile time and a Ruby-less Sass

This is probably the single biggest wish I have for Sass at present. The easiest way to remove compile time is to remove dependencies. However, I accept this can go too far (the fastest compile will obviously be no compile – just use CSS).

My compile time is often unacceptably (for me) long. I tend to use Grunt for everything I can. That includes generating the server, compiling/building out handlebar style templates, compiling my Sass and LiveReloading the changes to the browser. The time it takes to compile Sass with each change has always been the weak link in the Grunt chain.

As an example, the current project I’m working on was taking 12+ seconds to compile. That’s without Compass (which can often add additional compile time) but using Bourbon. Removing Bourbon and using Autoprefixer instead dropped compile time to around 4 seconds!

It may sound crazy but even 4 seconds is 4 seconds too long. Some of that time can be attributed to using Grunt to compile. As I understand it, on each compile, Grunt has to spin up an instance of Ruby to compile the Sass. This makes it slower than watching the files for changes natively. As an example of the difference: compiling the same project directly with Ruby Sass (Bourbon @includes still in and no Autoprefixer) reduced the compile to around the 8 second mark.

If you’re sticking with Grunt, from my anecdotal empirical evidence it would seem that the most ‘expensive’ things in a Sass project are @include,@imports and @extends. You can see from my earlier numbers, ditching Bourbon (which has lots of @imports itself) dropped compile time significantly (roughly 12 to 4 seconds). Introduce too many @extends, @includes and @imports into a project and things quickly start to creak.

Out of curiosity, before moving to Autoprefixer (e.g. using Bourbon and Grunt), I wondered if pre-compiling my partials into a single ‘partial’ file with Grunt-concat (for example, making one _compiled-partial.scss file out of the 20+ modular partials I had previously) and then running Grunt on the single pre-compiled ‘partial’ would speed things up. This did show some benefit, reducing Sass compile time by a couple of seconds but it wasn’t a sustainable approach and didn’t feel like enough of an improvement to warrant the hacky approach.

All the workaround arounds I have mentioned are just that: workarounds. Regardless of how you want to write your Sass or what Sass libraries you use, there is something far, far better that’s almost ready for prime time that will solve the compile duration problems.

All hail libsass!

Some time ago I wrote about Lightning fast Sass compiling with libsass, Node-sass and Grunt-sass. It’s no exaggeration to say that once you have compiled with Grunt-sass/Node-sass (in turn the wrapper for libsass) you’re ruined. Anything other than the near instant compilation you get from Libsass just seems too slow.

For me, the highlights the fact that the sooner that a fully featured Sass (currently libsass lacks some crucial features such as full @extend support) can be run easily and independently of Ruby the better. Sure the Ruby users out there won’t benefit but I’d venture there are as many (maybe more) users out there using Sass outside of Ruby based projects. I can only see that number increasing.

At present libsass won’t properly compile @extends and has no support for source maps. As I’ve already mentioned, I can easily live without source maps but I can’t do without @extends.
To this end, I’ve set up a bounty on that feature. Whenever the libsass folks figure out the full implementation of @extends, I will be glad to think they can enjoy a drink on me.

I’m really curious to hear from other Sass users out there who work with Sass all day everyday. Are the features you get most from day-to-day the features you thought you would get most out of?