Why I Don’t Use Compass Anymore

By Hugo Giraudel

Compass is one hell of a project. It is by far the biggest Sass framework out there and since it is maintained by Chris Eppstein himself, one of the two Sass core designers, I don’t see it losing in popularity anytime soon.

Yet, about a year ago or so, I stopped using Compass altogether. I removed it from our project at work. I removed it from my own site. I removed it from most of my side projects. So what happened? How could I move from “Compass is the best” to “I don’t need it anymore”?

I think I just got better and more confident with Sass, to a point where Compass did not bring much to the table anymore. At least, it was not enough to be worth including it in a project, especially given that it slows Ruby Sass, already quite slow in itself…

Let me put something straight before going any further: in no way am I saying that Compass is useless. Neither am I saying that you should get rid of Compass. I only want to show you other options and other ways of doing things, that do not require Compass to be part of the project.

Now, to fully get why we can or cannot remove the Compass dependency, we need to understand what does Compass do at the end of the day. According to the docs, Compass provides:

Everything else is pretty much accessory.

Autoprefixer does the same

Before Compass 1.0.0, prefixes were managed manually in Compass. It means whenever a new prefix was born or passed away, a pull request had to be submitted to Compass to remove the prefix from the relevant mixin. Not ideal… That’s why Chris moved to something smarter in v1.0.0, pulling data directly from CanIUse.

Meanwhile, the very popular Autoprefixer library does the same. So at this point, both Compass and Autoprefixer are 100% up-to-date with vendor prefixes, yet there is still a major difference: you still have to use Compass mixins to prefix your properties and values, while Autoprefixer does it as part of your deployment process, post-processing your stylesheets.

In order to have the following CSS output:

.unicorn {
  -webkit-transform: translateX(42em);
  -ms-transform: translateX(42em);
  transform: translateX(42em);

You need to write this in Compass:

.unicorn {
  @include transform(translateX(42em));

And this with Autoprefixer plugged in:

.unicorn {
  transform: translateX(42em);

Not only is the latter easier and shorter, also in the hypothetical and marvelous future where we no longer need prefixes for the transform property, we don’t have to come back to the code to get rid of the mixin call. It’s all good.

You don’t need math everyday

I like how Sass provides us with the ability to perform math operations within our stylesheets. When we think about CSS preprocessors, we often mention variables and mixins, yet omit math support. This is a huge deal for a number-based language such as CSS.

On top of that, Compass provides a few advanced math helpers, such as cos, sin, tan, sqrt, pow, pi and, perhaps, less usefully acos, asin, atan, logarithm and e. In some cases, I have to admit having access to those functions might be useful. For instance,
in a previous article I used cos and sin to build the perfect long-shadow mixin. A while back, I remember needing sqrt to properly align rotated pseudo-elements as part of a step-wizard. So there are use cases.

Yet, they are so uncommon that I cannot consider Compass’ math helpers a valid reason to keep it in a project. It, for me, is just too anecdotal at this point. Especially since most of those functions can be polyfilled with nothing but Sass (thanks to basic math operations). For instance, here is a pure Sass version of the pow function:

/// Power function
/// @param {Number} $x
/// @param {Number} $n
/// @return {Number}
/// @source Sass-Math
@function pow($x, $n) {
  $result: 1;

  @if $n >= 0 {
    @for $i from 1 through $n {
        $result: $result * $x;
  } @else {
      @for $i from $n to 0 {
        $result: $result / $x;
  @return $result;

If you extensively need advanced math functions in Sass, may I recommend having a look at Sassy-Math, a lightweight Ruby Sass library providing everything math. If you want to polyfill a math function yourself, have a look at this article. Also, Ana Tudor has written about inverse trigonometric functions in Sass at The Sass Way.

You can polyfill color functions

I must say I am not an expert with Compass color functions since I never used any of them. The thing is Sass already provides so many native functions to deal with colors that I never felt like some more were needed.

Although, that’s not entirely true. In Sass Guidelines I explain how I think using the mix function is often more appropriate than darken and lighten. To make using mix slightly easier, I wrote two very short functions that happen to exist in Compass:

/// Slightly lighten a color
/// @access public
/// @param {Color} $color - color to tint
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function tint($color, $percentage) {
  @return mix($color, white, $percentage);

/// Slightly darken a color
/// @access public
/// @param {Color} $color - color to shade
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function shade($color, $percentage) {
  @return mix($color, black, $percentage);

Anyway, there again I don’t think this is enough to keep Compass exclusively for this.

You can do without image helpers

Let’s get to the real thing. Compass, being that it is written in Ruby, provides image helpers such as image-width and image-height that return an image’s dimensions based on a given path. How great is this, especially for image replacement techniques? This way you can size an element to fit an image, without worrying about the dimensions changing.

.logo {
  $logo-path: '/assets/images/logo.png';
  width: image-width($logo-path);
  height: image-height($logo-path);
  // ...

Unfortunately, there is no way for us to polyfill such a thing. Sass does not have access to the file system so it is not possible to figure out an image dimensions whatsoever.

That being said, I personally tend to use less and less images in my work when using SVG or any equivalent is an option. Because SVG stands for scalable vector graphics, I think the need to know exact dimensions is getting lower everyday. As far as I am concerned, I have not missed this feature for a while now.

SVG Sprite Builders are legions

Okay, now we’re talking. The sprite builder has always been Compass’s main feature if you ask me. And for that reason, it is extremely well thought and convenient. Building a spritesheet from an image folder only takes a couple of minutes with Compass, if not less.

@import "compass/utilities/sprites";
@import "my-icons/*.png";
@include all-my-icons-sprites;

Fine. While there were no strict equivalent for image helpers, we all know that there are countless sprite builders out there. Take Grunticon for instance, a SVG sprite builder running on Grunt. It even comes with a browser-based app entitled Grumpicon. This is probably one of the best since it has been released by Filament Group but there are plenty of other choices, running on whatever tool floats your boat.

So while it is nice having Compass doing that directly from our stylesheets, there are other options and it is indeed possible to handle sprites without having to use Compass. Along the same lines, I would find it very odd to use Compass only for the sprite builder, no matter how good it is. A sprite builder is a tool that can be completely dissociated from the stylesheet itself. There is no need for both to be intimately tied, even if it might present some benefits.

A word about LibSass

Compass is not LibSass compliant. Because it still is heavily tied to Ruby, it is not possible to use Compass in a “LibSass environment”. In a world where LibSass is getting more and more present every day, I think being engine-agnostic is a major goal. Obviously, Chris thinks the same and will work on porting it to LibSass.

Final thoughts

Moving away from Compass, if that’s what you want, should be relatively simple. First, make sure you do not use any helpers from Compass such as tint or sqrt. If you do, polyfill them in your function files (just Google them, you’ll find a pure Sass version soon enough). Then, get rid of all your CSS prefixing mixins and set up Autoprefixer in your project (if that’s possible, obviously). Last, move to a custom sprite builder if you need it.

Again, it is not that Compass is a bad tool or anything. Au contraire, Compass is a terrific framework! If you are happy with Compass, please keep using it. There is no point in dropping a tool you are happy with just because you read it from some article, so stick to Compass if you are fine with it.

On the other hand, if you wonder whether it’s worth moving away from Compass because you don’t use much of it, then you might consider getting rid of it, as I did.

Meet the author
CSS goblin. Sass hacker. Margin psycho. Author of Sass Guidelines, SassDoc, Sass Compatibility, Browserhacks and a lot of Sass stuff.

As someone who doesn't work in Ruby and likes to incorporate SASS into the build process, Compass has always seemed like an unnecessary extra to me.


Thanks for going ahead and saying this. For most part, I have never used compass or any of it's dependencies. In fact, my workflow would have zero ruby had it not been for Sass in the initial days. I like how we are all moving away from cluttered and confusing workflows to simple. Coming from you, especially, I think this is good education. I also enjoyed your other post on keeping it simple.


Nice! I stoped woking with compass on my projects too.
I appreciate the autoprefixr suggestion.
Compass sticky-footer is a nice nice compass module ( but is really easy to develop a custom solution. is a lighter alternative for css3 prefixes mixins.


Left Compass behind a while ago for Libsass and Autoprefixer. However - some of the projects I contract with require it. I found that manually porting in the Compass mixins (Igosuki has compass-mixins built for bower and libsass ) allows me to seamlessly contribute to Compass projects without affecting my build process


Nice writeup. I felt the same way a while back and really didn't see any usage for Compass after adding Autoprefixer into my workflow but recently brought it back since it's core dependency for breakpoint and I also discovered it has some nice helpers for inlining images and fonts.


I couldn't agree more. Whenever I'm working on a project that uses Compass I can't help but think it isn't even needed and definitely isn't worth the extra compile times.

Like you said it's incredibly useful for some people but I'm not one of them.


Oh forgot to mention. Compass contrast function is super rad. The one that you use to check if the background is dark or light and then set the text-color based on that is very useful. They also have a yiq color scheme, which is useful for when the previous function doesn't function properly. I didn't even know there was a yiq scheme but that was super useful when you design separately and hand over a styleguide to developers.


I've hated compass for ages. The mixins are so needlessly long!
The only reason I would use compass is for the auto-sprite but now that I've found Grunt Spritesmith I never have to use compass ever again! smiley


I agree with everything. I changed my whole scss boilerplate to a compass-free workflow, after all, I only used compass for prefixing anyway. I'm just very glad, that susy doesn't depend on compass anymore since 2.0.


The one thing that keeps me using Compass and that isn't mentioned in the article is plugins or extensions like Modular Scale.

Things like Susy and Breakpoint have moved away from Compass as a dependency, which is great. But there are still a few out there that require Compass, and even ones that can be used Sass only don't always have all of the same features as the Compass version.

Modular scale is faster and can only use non-integer values with Compass, for example.


Same here, I stopped using Compass about a year ago.

My circumstances for why I stopped using Compass are a bit different and nowhere near as elaborate as yours Hugo :p.,

When I started learning Sass dealing with vendor prefixes was problematic. Enter Compass. And that's basically the only reason I used it for. Nothing else.

I was compiling via the CMD so every time I wanted to use and advanced CSS3 property, I had to go hunt down the mixin in the Compass site, figure out where the mixin I needed was in the huge list of options and variations it has, then add it to the top of my main SCSS file and then call the mixin. For each and ever single advanced CSS3 property that needed prefixing.

Then I found Prepros and Koala App which allowed me to harness the power of Autoprefixer so all I needed to do was to write the CSS3 property as the spec said and be done, no worries about prefixing anymore.

Truth be told, I owe a lot of the little I know about Sass to Compass because although it was a lot of work implementing its mixins, it allow me to see and understand the power of Sass and question my own process and become a better professional.

Thanks for sharing Hugo.


I'm a little trapped in compass because of the awesome font mixin @include font-face() and
inline-font-files() to convert them to base64, do you know any replacemente for this?


Great article. I've been using Compass but will now look at removing it from our web app project. Thanks.

btw - saw a couple of typos in the article:
* SVG Sprite Builder are legions > SVG Sprite Builders are legion
* there are countless of sprite builders > there are countless sprite builders
* plenty of over choices > plenty of other choices
* whenever a new prefix bore or passed away > whenever a new prefix [?] passed away


Shameless self-promotion: Last week I published a gulp-plugin for polyfilling the compass image-helper functions:


@phlppschrr So why don't you post it in the Showcase category and tell us a bit about it? smile


Hey Adrian – Thanks for catching these. I've edited the article and updated it. Let us know how you get on removing Compass! smile


What's about vertical rhythm?


Great article.

I'm trying to ditch Compass but I'm trapped with the image helpers, I find them really useful as I work with a lot of images in my projects, designers in my team seem to love background images, so I still use them. Any advice on a cool ruby-gem doing just the image helpers thing?


If you prefered Autoprefixer rather that Compass, maybe you should look at PostCSS. Autoprefixer is based on this CSS processor, like Compass is based on Sass. And PostCSS has many other great tools:


I thought you're going to recommend a new super all-in-one solution. But no, you're now breaking your project's dependencies into multiple tools instead of just one. Why would i do that?

And libsass is always behind compared to the original ruby-sass in terms of functionality. So that's another no.


One of the key things for me is Compass' typographic functions and mixins. Do you not find these useful to work with when establishing a vertical rhythm?

Although I could switch away from using Compass I haven't really seen any negative side effects to using it in contrast to just plain Sass but lots of positives in terms of already having a pool of useful and well documented functions, mixins, and utilities. If you end up creating several of those yourself I don't really see the advantage and it just means that others picking up the projects (including your future self) have less documentation and a less familiar base to pick up with.


After being literally forced to look for an alternative due to horrible performance as my projects got bigger, WOW, thank you for this suggestion. Cleaner code AND acceptable performance with autoprefixer. What the heck was I using Compass for? Goodbye forever.

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!