I was first introduced to SASS early last year. The agency I was working with at the time (Evolution Bureau) began having a series of tech talks amongst the developers where we would introduce each other to different technologies we were excited about; my friend Josh gave a little presentation about his favorite CSS preprocessor.
For those who aren’t familiar, SASS is a CSS extension language. The syntax is immediately familar to anyone used to writing CSS, but it includes many handy capabilities that naked CSS doesn’t have, such as variables, nesting, functions and mixins. There is a compiler that can be set to monitor your SASS directories which will compile your SASS documents into CSS every time you save them, making them easy to work into your normal development flow. The result is much more maintainable stylesheets.
Needless to say, it looked impressive. But something about it just didn’t feel right to me.
It seemed weird to have a critical part of an application (the stylesheets) entirely generated by a tool running on a developer’s machine. I couldn’t quite put my finger on why, exactly; it’s just weird. Like, say there is some old website quietly humming along somewhere for a couple years. All the original developers have left, and you get tasked with updating some of the pages. Mostly just content updates, but a lot stuff needs to be rearranged and formatted. You download the site locally, pop open the CSS file to start your work and what do you see? Thousands of lines of machine-generated CSS rules. Maybe you can find the original SASS file on there somewhere (it isn’t technically used by the production site, so there is a chance it wasn’t pushed) but even then you have to set up your local machine to compile it and drop it in the same directory as the old files.
It’s sort of like a code smell. Your code is no longer self-contained, and if SASS were to get hit by a bus tomorrow, your site would be very hard to update.
Fast forward a few months. I started work on another project with a different company, building a responsive site with Foundation. I had to start using SASS every day. And you know what?
It really is awesome. I’m not sure I would go back to using naked CSS if given the choice.
An article I read last week reminded me of my original thoughts about SASS, though. Matt Greer wrote Coffeescript’s Time is Waning to explain the reasons why he won’t likely use Coffeescript going forward; roughly speaking, Coffeescript is to Javascript what SASS is to CSS.
The core of his argument is that as Javascript/ECMAScript is evolving, it is incorporating many of the features that made Coffeescript compelling; as browsers (and Node.js) start to support the newer standards, he is finding the friction of using the intermediate language to be harder to justify.
I could easily see something similar happening to CSS. Coding with SASS and other preprocessors is just so much more efficient that it seems inevitable that standards bodies and browser vendors will start bringing their best features into the core product, ultimately making them redundant. And this is as it should be.
Some technologies are transitional by nature, a bridge that must exist from the “bad old days” to something new and better. I think “transitionalness” is what I couldn’t put my finger on originally; that as great as the tool is, the fact that it isn’t a core technology made it feel like a mile marker rather than an final destination.
Of course, we don’t know what the future looks like. In the meantime, I’ll continue to pick the best tool for the job.
