Below is a statement made to me a short time ago by someone on Twitter named David Leuliette (translated from French):
— David Leuliette, Twitter
So far I have to say the analogy has some merit. To be honest, it is not something I had previously given any thought to but now that the idea is on the table, let’s try to dig a little deeper into it to see if we can come to a definite conclusion.
Let’s compare the things we’re talking about here:
Sass in itself is more like a kind of program that compiles SassScript into actual CSS. So although the language itself is SassScript let’s oversimplify this and postulate that Sass is an interpreted scripting language.
Framework or library?
Meanwhile, as explained on its homepage, Compass is a framework for Sass projects, or a CSS Authoring Framework (whatever that means!).
Compass is an open-source CSS Authoring Framework.
So on one hand we have a library and on the other hand we have a framework. Before going any further in our comparison, we should probably have a look at the main difference between a library and a framework. Although the terms are often used interchangably, I’ve done some research to help us define them more accurately.
Two quotes I dug up tell us that a framework is more global than a library, whereas a library is something quite specific that you can call whenever you need it.
A library performs specific, well-defined operations. A framework is a skeleton where the application defines the “meat” of the operation by filling out the skeleton. The skeleton still has code to link up the parts but the most important work is done by the application.
— Jason Cohen, Stack Overflow
A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points.
— Martin Fowler, Inversion of control
Further, here are two moer quotes one from discussing a software design methodology called the Hollywood principle:
I think that the main difference is that frameworks follow the Hollywood principle, i.e. “don’t call us, we’ll call you.”.
— Panos, Stack Overflow
You call Library. Framework calls you.
— Ian Boyd, Stack Overflow
And finally a quote that sums it all up:
A library is a tool. A framework is a way of life. A library you can use whatever tiny part helps you. A Framework you must commit your entire project to.
— James Curran, Stack Overflow
Compass on the other hand not only provides a collection of mixins to the user, but also a whole range of other features like images and path manipulation, sprite building, blueprint, and much more.
From there, we could raise the first flag on our comparison: in a way, Compass is more than jQuery.
Do we need them?
Nowadays more and more people are avoiding jQuery for various reasons:
- Standards and browsers are moving forward, making some jQuery features unnecessary.
At best, Sass will compile stylesheets a bit faster without Compass but I’m not sure you can actually perceive any difference. Also, I’m not sure giving up all the tools and shortcuts Compass offers is actually worth a slightly faster compilation. In my opionion, it definitely isn’t worth the sacrifice.
What Can We Conclude?
On the other hand, if we disregard the technical definitions of “library” and “framework” then the answer might be: kind of. In a way, using Compass for mixins is very similar to using jQuery for functions. It’s less verbosity, it makes things simpler, and more readable, and thus is easier to maintain. This is quite similar to what jQuery does.
But as discussed, in the end, pragmatism wins: The real difference between Compass and jQuery is that while there are benefits to avoiding jQuery, I don’t see any reason to give up Compass.