I was a reluctant believer in Sass. I write stylesheets by hand! I don’t need help! And I certainly don’t want to add extra complexity to my workflow. Go away!
That was the thinking anyway. But the reality is that Sass (and other CSS preprocessors) can be a powerful ally—a tool that any style-crafter can easily insert into their daily work. It took me a while to come around, but I’m sure glad that I did.
And that’s the reason I wanted to write this little book. To share how I’ve been able to use Sass to be more efficient, while maintaining the process I’ve become comfortable with from writing CSS for the last ten years. I had many misconceptions about Sass that prevented me from giving it a go, initially. I was worried I’d have to completely alter the way I write and manage stylesheets. As CSS can be fragile at times, it’s understandable for its authors to be somewhat protective about their creation. Can I get an amen?
Ahem.
So, I’m here to show you how Sass doesn’t have to disrupt your process and workflow, and how it can make your life easier. I’ll demonstrate the various aspects of Sass, how to install it, how to use it, and how it’s helped me in my own projects. With any luck, I just might make you a believer as well.
The Sass elevator pitch#section2
Ever needed to change, say, a color in your stylesheet, and found that you had to find and replace the value multiple times? Don’t you wish CSS allowed you to do this?
$brand-color: #fc3;
a {
color: $brand-color;
}
nav {
background-color: $brand-color;
}
What if you could change that value in one place and the entire stylesheet reflected that change? You can with Sass!
Or how about repeated blocks of styles that are used in various locations throughout the stylesheet?
p {
margin-bottom: 20px; font-size: 14px; line-height: 1.5;
}
footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
Wouldn’t it be fantastic to roll those shared rules into a reusable block? Again, defined only once but included wherever you needed them.
@mixin default-type {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
p {
@include default-type;
}
footer {
@include default-type;
}
That’s also Sass! And those two extremely simple examples barely scratch the surface as to how Sass makes authoring stylesheets faster, easier, and more flexible. It’s a welcome helper in the world of web design, because anyone that’s created a website knows…
CSS is hard#section3
Let’s face it: learning CSS isn’t easy. Understanding what each property does, how the cascade works, which browser supports what, the selectors, the quirks, and so forth. It’s not easy. Add on top of that the complexity of the interfaces we’re building these days, and the maintenance that goes along with that and—wait, why are we doing this again? It’s a puzzle, and some of us enjoy the eventual completion.
Part of the problem is that CSS wasn’t originally designed to do the things we do with it today. Sure, progress is moving along at a nice clip thanks to rapid browser innovation and implementation of CSS3 and beyond. But we still need to rely on techniques that are, for all intents and purposes, hacks. The float property, for example, was designed to simply align an image within a block of text. That’s it. Yet we’ve had to bend that property to lay out entire interfaces.
Our stylesheets are also immensely repetitive. Colors, fonts, oft-used groupings of properties, etc. The typical CSS file is an extremely linear document—the kind of thing that makes an object-oriented programmer want to tear their hair out. (I’m not an object-oriented programmer, but I have very little hair left. Read into that as you may).
As interfaces and web applications become more robust and complex, we’re bending the original design of CSS to do things it never dreamed of doing. We’re crafty like that. Fortunately, browser makers adopt new CSS features far more rapidly these days, with more efficient and powerful properties and selectors that solve the problems today’s web poses. Features like new layout options in CSS3, border-radius, box-shadow, advanced selectors, transitions, transforms, animation, and so on. It’s an exciting time. And yet, there’s still a lot missing from CSS itself. There are holes to be plugged, and the life of a stylesheet author should be a lot easier.
The DRY principle#section4
If we peer into the world of software engineering (and I much prefer to peer than hang out and get comfortable there), we can quickly see how organization, variables, constants, partials, etc., are an ingrained, crucial way of working for folks building complex systems.
You may have heard of the “don’t repeat yourself” (DRY) principle. Coined and defined by Andy Hunt and Dave Thomas in their book, The Pragmatic Programmer (http://bkaprt.com/sass/1/), DRY declares:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
The idea is that duplicating code can cause failure and confusion for developers (http://bkaprt.com/sass/2/). It’s common sense as well: write commonly-repeated patterns once, and reuse those bits throughout the application. It’s more efficient and far easier to maintain code this way.
CSS is anything but DRY. At times, it drips with repeated rules, declarations, and values. We’re constantly writing the same snippets of code for colors, fonts, and frequently-used patterns of style throughout our stylesheets. One look through a decent-sized CSS file, and a DRY software developer will weep, first with bewilderment, then frustration.
“How the !@#$ do you maintain this?!” they’ll ask.
“Have I also told you about IE bugs?” you’ll reply with a bit of self-loathing.
So why is CSS so difficult to work with?#section5
We can gather a hint of understanding why CSS has had its syntax limitations over the years from an essay by CSS co-inventor, Bert Bos (http://bkaprt.com/sass/3/):
CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance. And for CSS the balance is different than for some other things.
The original architects of CSS were concerned with adoption. They (rightfully) wanted as many people as possible creating websites. They wanted CSS to be powerful enough to style web pages and separate content from presentation, while being easy to understand and use. I can certainly respect that. At the same time, we have work to do, and that work is getting more complicated, more nuanced, and more challenging to maintain and to future-proof.
Fortunately, there are options to help us out here, and one of them is Sass.
What is Sass?#section6
Sass is a CSS preprocessor—a layer between the stylesheets you author and the .css files you serve to the browser. Sass (short for Syntactically Awesome Stylesheets) plugs the holes in CSS as a language, allowing you to write DRY code that’ll be faster, more efficient, and easier to maintain.
The Sass website (http://bkaprt.com/sass/4/) describes itself succinctly:
Sass is a meta-language on top of CSS that’s used to describe the style of a document cleanly and structurally, with more power than flat CSS allows. Sass both provides a simpler, more elegant syntax for CSS and implements various features that are useful for creating manageable stylesheets.
So while normal CSS doesn’t yet allow things like variables, mixins (reusable blocks of styles), and other goodies, Sass provides a syntax that does all of that and more—enabling “super functionality” in addition to your normal CSS. It then translates (or compiles) that syntax into regular ol’ CSS files via a command-line program or web-framework plugin.
More specifically, Sass is an extension of CSS3, and its SCSS (“Sassy CSS”) syntax—which we’ll talk about in just a moment—is a superset of CSS3. Meaning, any valid CSS3 document is a valid SCSS document as well. This is integral to Sass being something you can “ease into.” Getting started with Sass syntax is painless, and you can use as little or as much as you’d like. Which also means converting an existing stylesheet from CSS to SCSS can be done in stages, as you learn and pick up more of Sass’s functionality.
Later, when you’ve become fluent with Sass (and it won’t take long), it really does feel like a natural extension of CSS—as if it’s filling holes we all wish were filled by the CSS spec itself. This is why, once I started using Sass, I never once thought it was awkward or laborious—it just feels like CSS should feel. Once you try it, you’ll likely stick with it permanently.
Furthermore, Sass is helping CSS get better. By fast-tracking certain features that aren’t currently possible without the help of a preprocessor, it’s giving CSS authors real-world implementation and feature experimentation. When and if it makes sense, certain Sass functionality could very well inform future CSS specifications.
Sass misconceptions#section7
I mentioned earlier that I was reluctant to try Sass. This was partly due to a lot of misconceptions I had prior to using it. Do I need to know Ruby or advanced command-line shenanigans? Will I need to completely change the way I’ve been writing stylesheets? Will the CSS it outputs be bloated and unreadable?
Thankfully, the answer is “nope” for each of those questions, of course—but I do hear them pop up whenever someone mentions Sass on various internet channels. Let’s clear up a few things.
I’m afraid of the command line!#section8
I am by no means a command-line expert, but I’ve learned a bit here and there over the years—just enough to get me into trouble. I’m not afraid to traverse the file system with it or use Git commands, etc.
That said, I sympathize with designers and front-end developers who don’t want to go there. There’s a command-line phobia that exists among some folks. For Sass, there’s very little command-line action required—in fact, a single command is all you need to grasp. Additionally, there are apps and web frameworks that will obviate the need for the command line. (I’ll be introducing those in the next chapter).
So, if you’re a command-line avoider, don’t let that stop you from trying Sass!
I don’t want to change the way I write CSS!#section9
This was the misconception that I suffered from. I’m particular about the way my stylesheets are set up and organized. There’s a certain amount of craft that goes into the document. But remember, since the SCSS syntax is a superset of CSS3, you don’t have to change anything about the way you write CSS. Commenting, indenting, or not indenting, all your formatting preferences can remain the same when working in .scss files. Once I realized this, I could dive in without fear.
I don’t want Sass to change the way I design!#section10
On the flip side, Sass won’t solve all of your problems or cure your bad habits. Inefficient, bloated stylesheets can be just as inefficient and bloated when using Sass. Good organization and smart thinking still apply here. In fact, there are instances where Sass can magnify bad practices, and we’ll go into that a bit as well. But when used properly and intelligently, Sass can be such a massive assist in creating websites.
Okay. Now that we have the particulars out of the way, let’s start having some fun. I think you’ll be amazed at what Sass can do. In the next chapter, we’ll set up our workflow—how Sass can fit into your process and how easy it is to use the command-line or apps. Let’s get Sassing, people.
Couldn’t agree more. I now wonder how we lived before SASS.
Having said that, it does not do everything well. I think SASS has shown us the way but something better must be in the pipeline. As soon as you start getting into the nitty gritty and writing functions you realise how limited you are in terms of language itself, e.g. lists (arrays), variable types, basic mathematical operations.
What i’d like to see is the ability to write some blocks using plain javascript, like for/next loops, objects, arrays, if/else etc. So many people already know how to use js and css so if we could mix the two that would be perfect.
Great article! We feel the same way, and hopefully in the future the question will become “Why not SASS?”.
Take a look at our recent posting that runs through the points of why SASS is great: http://goo.gl/vDAtls
SASS does have some advanced logic support (if/else, for, each, while). Explore some of the community extensions/mixins and you’ll find some clever people have put these to very good use.
I am working with LESS but I wonder why you say that CSS is hard, it is one of the most easy language
I have long been fearful of diving into SASS, but your article has given me the courage to take the plunge.
@OhmzTech – i know SASS has support for if/else, for, each, while etc. but it’s not anywhere near as powerful as javascript and you quickly come up against it’s limitations.
Sometimes there are good external solutions, for example SassyLists does a great job of providing a lot of missing functions for working with lists, but JS arrays are still much better.
This is music to my eyes. My 2004 copy of Web Standards Solutions by Dan in conjunction with Designing With Web Standards was what started it all for me. And for once I am slightly less behind the curve for having already embraced SASS. But it will be great to read about it from Dan’s perspective as I am sure my use of SASS could do with a work-out.
For me, using SASS has seriously sped up the rate at which I code. If nothing else, the fact that I can keep all of my responsive selectors right there with the rest of the selectors (where it’s considerably easier to debug!) has been one of the biggest helps to me. You add that to the variables, mixins, etc. and you start wondering why you didn’t start doing this long ago.
This is more of an article on css preprocessors than SASS specifically. I think it does readers a disservice by describing benefits that most, if not all css preprocessors have, but then only mentioning SASS. I do like SASS, but this feels like an ad.
For someone still pretty green with CSS, using SASS/SCSS has actually helped me understand CSS itself. Also, coming from a C++ background I had always found CSS weird & confusing, almost an island unto itself. It seems simple enough plain ole CSS but with .’s and #’s to keep track of and all the repetition of code, looking at a massive style sheet and trying to make an edit to someone else’s work can be a project itself and many times in my experience a MUCH longer duration in time than the actual act of making the edit(s) everywhere needed throughout the style sheet. If one keeps their SASS/SCSS partial’d out making any edit(s) to a website/app’s style infinitely less frustrating and much much quicker than when not using a CSS-preprocessor.
Until the last year, despite being a js developer, I was relatively hostile to the command line, and installing/updating ruby can also be a real drag. Then I came across Scout, a cross-platform, simple to install sass-watching gui http://mhs.github.io/scout-app/. It’s fantastic and, good article though this is, I’m really surprised Scout isn’t mentioned at all as it instantly gets rid of, I would argue, the biggest barrier to sass adoption.
Great to see this on ALA!
Also, Sass takes implementing object oriented CSS approaches like SMACSS and BEM to the next level. I wrote a little introduction on how to get started with this for anyone interested:
https://medium.com/objects-in-space/f6f404727/
Our organization is already seeing huge gains from this approach. Feel free to drop me a line on this if you want to learn more.
Ruby and Sass it’s not too heavy ?
Dan, could you please explain why you like using sass or why you choose sass over other preprocessors?
Look forward to reading this book, Dan has taught me a lot through reading his books and am always eager to see what he has to teach about what’s new. Already a Sass devotee but keen to expand my knowledge as I still haven’t explored all the possibilities.
1. If you fear the command line, Prepros (http://alphapixels.com/prepros/) is an awesome solution that handles preprocessing your SASS (&, yes, LESS, if that’s your thing), PLUS a bunch of other things (Haml, Jade, CoffeeScript), minifies Javascripts, optimizes images, handles browser live refresh, brings you fresh tea. Highly recommended, esp. if you’re coding on Windows machines, like me. (I previously used Scout, but find Prepros to be a big step up.)
2. Comments should bear in mind this is an excerpt for a book. So, yes, it’s SASS-centric and it doesn’t cover all the bases.
Dan, interesting read, but … what I see in articles like this a lot has happened again. Technology A can be improved by utilizing Technology B. All true, here. CSS is easier to maintain with the help of precompiled SASS. And command line issues _are_ irrelevant learn or use one of the GUIs (like CodeKit or Prepos).
But what about Technology C, which is arguably easier to learn because it actually resembles Technology A: try Less. Leaving Less out of this article seems crazy. I’ve worked on year long projects with both and there’s a lot to be said for Less … Less syntax _is_ very much like CSS syntax. And most importantly, you can cut & paste or @import .css files directly into your Less files … no re-writes (unless you want to).
Lastly, the best reason to use Less is the less.js client side compiler which completely eliminates the need to use a command line or GUI compiler until you’re work is (nearly) done.
Sass or Less are both good options and once you go down this path, you won’t go back. You’ll incorporate either into your build & deployment processes. And for even the smallest projects you’ll want to use precompiled CSS for its brevity.
Especially when you take advantage of mixins to automagically handle repetitive things like that .clearfix class you always use. Or to help with vendor prefixes … or to make CSS animations or drop-shadows a cake walk …
Great article but shouldn’t it include a link to the book it’s excerpted from somewhere?
I develop using LESS for 2 years and I agree with what Paul Griffin Petty says in comment # 16 “Less syntax is very much like CSS syntax” with LESS I can do the same as those used for achieving SASS I need, I can create my own parameter-mixins, mixins, namespaces etc … not saying it’s better but I prefer my taste LESS 🙂
As for what you said Erick Boileau in comment # 3
I’m sorry but I disagreed with his opinion,
css not just change colors or add margins or paddings, to understand well you have to know how to interpret the DOM, which elements have their default value display property, inheritance, specificity, bubbling up bottom to left read file, reflow, repaint and could continue with an extensive list, if you keep thinking it’s easy just prove how brainy you have no idea what you do.
I’ve worked with ASP.NET and there’s a package called dotless which, with a quick configuration update, will automagically convert LESS to CSS when it’s served, no command line needed (especically if you know about the GUI for NuGet, which a lot of people don’t).
I’m primarily a server-side developer, yet I HATES me some SASS. Such an utterly unnecessary layer that adds exponential amounts of complexity for everyone involved. The time it takes to get each developer “set up” properly is time that could have been used creating proper classes so that you can indeed have a “DRY” stylesheet.
I’m not even going to get into the hell of trying to do real-time debugging in Chrome dev tools, etc. Instead I’ll post a link to this lovely piece: http://blog.millermedeiros.com/the-problem-with-css-pre-processors/
Tried Sass briefly but never wanted to adopt it, i think it was the fear of changing the way i work, but this article (hope i can get Dan’s book) changed my mind.
Thanks.
For me, the command line thing was annoying; what I ended up using to compile SASS was Codekit which works very well.
(http://incident57.com/codekit/)
What is better code wise, content blocks of CSS getting repeated in the CSS file or one class name getting added multiple times to the HTML? blockitis or classitis : )
Looking forward to reading this book and being more educated on SASS.
@Brad Garrett – If it’s slowing you down and you don’t know how to debug it then I’m afraid you’re doing it wrong. A classic case of blaming the technology because you don’t understand it.
@Jon Hobbs-Smith — Thanks, bro. Why bring evidence and use-cases to the table (like I did) when you can simply deliver a keen put-down. Do enlighten us with your secret knowledge of why this technology is so superior!
Examples of real-time debugging in the browser will net you mega bonus points–and yes, I know about Chrome’s “enable source maps” and “auto-reload generated CSS” but guess what? It simply doesn’t work most/all of the time, and there are times when clicking a rule in the inspector takes you to the wrong source file. I eagerly await your response.
Wahey! It’s about time designers started to write efficient CSS. Just wait till you progress to this.
https://en.wikipedia.org/wiki/Single_responsibility_principle
@Brad Garrett – well it makes my life much much easier and much quicker so I’m not sure how it can be slowing you down, if it is then the only logical conclusion is that you must be doing something different. Until you can explain why it slows you down then I’d just be guessing at a solution for you but in my eyes writing….
@include columns(5);
… is a lot easier than writing all the css to produce a grid in a responsive site (including 6 different versions wrapped inside 6 media queries).
Equally – SASS 3.2’s ability to wrap content with a mix allows you to do this..
@include breakpoint(large){
/* Increase font size */
}
In vanilla CSS you have to litter your stylesheets with hundreds of similar media queries and maintaining them is a nightmare. How is this not easier than plain old CSS. I’m genuinely interested to hear how it’s slowing you down.
With regard to debugging, I don’t know how your compiler is adding the wrong debug information(i compile with grunt and it works) but that’s the only explanation I can think of for source maps not working.
I would add though, that if you’re relying on developer tools to find the line number of the rule that’s causing a problem then how come you don’t know where that rule is? Personally I never use line numbers to find a rule, I know where it is because I structure my SCSS into a sensible file structure and nest rules inside one another in an easier to follow way. It makes it easier for me to find and fix problems and it makes it easier for other people in the team too because it’s structured well.
If you don’t already know about atomic design, SMACSS and OOCSS then give these a read. You’ll find debugging a lot easier when you’re not doing it by line numbers……
http://coding.smashingmagazine.com/2013/08/02/other-interface-atomic-design-sass/
http://smacss.com/
https://github.com/stubbornella/oocss/wiki
@Jon That’s better, thanks for the links! I think the thing with me is that I never felt hamstrung by normal CSS. I tend to organize my rules in a fairly sensible fashion (resets and type selectors first, then ID/class selectors in the order they appear on the pages) and keep all the rules per selector on one line when possible. This ensures my CSS doesn’t end up thousands of lines long but is still readable and easy to debug.
The problems I’ve run into recently is trying to make quick CSS changes to sites developed by other people, and several of these use SASS. I used to be able to do this w/ Chrome dev tools in a heartbeat. Now I had to go thru the whole ruby/sass setup process (and using source maps is apparently a “pre-release” SASS feature, which means I had to upgrade my version of Ruby to get it working). And because of all the inheritance shizz going on, I think Chrome gets confused about where the relevant rules for some of these elements originates.
I don’t have a problem w/ the OOCSS concept–of course it’s better to use classes instead of ID’s where possible so you can achieve DRY status and smaller CSS files. But I think this has always been the goal and doesn’t really need a special name. Same goes for SMACSS — it provides some good guidelines, but the last paragraph on this page is very key: http://smacss.com/book/selectors
Ultimately I feel like SASS is overkill for most/all sites. If we agree to disagree, that’s fine. But the whole setup and debugging process has now become more of a hassle than necessary with all the new intermediate steps.
I have to say I’ve been intrigued by SASS for a while, but have been slightly intimidated for the same reasons you outline above. I think I’ll take your recommendation as a sign I should dive in! Thanks and looking forward to reading more.
Thanks for clarifying some of the most debated aspects of SASS. Great article!
Wow! All of my worries and reasons for not trying SASS, obliterated! Although I wonder if CSS in the future could/would simply adopt things like this (below) and simply cut out the middleman…?
$brand-color: #fc3;
a {
color: $brand-color;
}
What’s the difference between writing
@mixin default-type {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
p {
@include default-type;
}
footer {
@include default-type;
}
and
p,
footer {
margin-bottom: 20px;
font-size: 14px;
line-height: 1.5;
}
With the first method I see the risk that people start overwriting stuff that they want to change for this particular selector – bloating up the code. Experienced coders won’t do this, but experienced coders can also write the second method.
$brand-color: #fc3;
I’ve seen it too often that people write things like $red: #f00. What when your color changes from red to blue? Again: Experienced coders won’t create variable names like this, but experienced developers are also able to use the search & replace function.
My main worry is that unexperienced coders won’t learn CSS properly anymore which will lead to bloated & unstructured CSS. CSS itself is very powerful and easy to learn, beginners simply have to understand HOW to use it properly.
Do pre-processor really make our life “easier” or do we just become lazy?
Also when I had to deal with a JAVA project I always made fun of the developer folks because their setup felt totally weird and overloaded to me. In such an environment it always took ages until I was able to finally SEE something and whenever something was broken it was a big hassle to make it work again. I then always told them: Look at the front end, writing a line of CSS, reloading the browser window and BAM – results. Front end development has always been super easy and by introducing more and more parts to our toolchain it’s becoming the opposite. Without reason.
JM2C
@Brad Garrett if it’s overkill for you then I totally understand, there’s a certain amount of inertia in moving to SASS, but it sounds like you’ve done a lot of the hard work in getting it set up so why not give it a go.
I used to put all my CSS rules on one line too and it certainly cuts down on the number of lines of code but one of the unexpected benefits of moving to sass was that because I could divide components (e.g. header, footer) down into smaller files I was able to go back to having everything neatly spaced and nested on different lines but having no more than a couple of hundred lines in each file. Sweet.
The last thing I’ll say is that I didn’t believe it fully until I threw myself into SASS. I’m still finding new tips and tricks which save me time which I couldn’t have known about before I got into it, I’m glad I took that leap of faith. I could try to list everything that’s good about SASS but you won’t really understand it’s true power until you start writing your own functions/mixins etc.
When jumping between projects using SASS and others that don’t, its the really simple things I miss most, nesting and variables save so much time and although extends and mixins can be dangerous – when used properly they save time AND help maintain/enforce a consistency which coming from a design background is high on my list!
As for some comments saying by using/learning sass you won’t know how to write css – I don’t think thats possible, its like saying you wont understand html if you write in HAML or Markdown – It can only build on what you already know.
My 2 cents
I love sass and css. Is really css so hard? or its the protocol and the orientation of css obscure? css is a piece of cake, sass makes the standards of making css a real chump. I prefer less, but i really prefere css, no mixins
There are some people debating the statement that “CSS is hard” and it is true that the language itself is not difficult, but I don’t think that’s what the author meant.
When you use just CSS and HTML in order to make websites that are very usable and have a great design then it can make a simple language like CSS into something very complicated.
Simply put, if web design was easy then there wouldn’t be so many terrible websites.
I must be missing the point here a bit so will have a go at SASS and LESS to rationalise, but for it seems apparent to me that by using CSS properly with classes and well-formed HTML you would negate the need for a lot if not all of these justification for bloating the process. It is about time standards got a move on though, surely Shapes and Regions are what the design world has been praying for since 1994!
For complex sites with lots of divs and conditions to match (show X on this page but show Y on another, show some div for one language but not for another, etc), SASS is a godsend. The DRY principle is much easier to stick to this way.
For smaller sites it might be overkill, but then again I prefer starting the project with SASS just in case I will need to make more complicated adjustments later on. For me at least, it’s just more fun coding with SASS than with straight CSS.
Dan, I’m a great fan of all of your books. Regarding content and the way you’re writing. Therefore I think I will give SASS a try even though I have similar concerns.
I didn’t read through the comments, so forgive me if someone else has said this. I think when scss was introduced is when I really adapted sass since my files were no longer whitespace-dependent. I tried other CSS preprocessors (mainly stylus) but the whitespace compilation errors were just killing me when I’d have to debug that crap.
At work, I was fortunate enough to come in at a time when we were choosing our technologies to work with for our site redesign and scss was tops on my list.
As mentioned in the article, bad practices can still run rampant with sass, so it won’t magically fix badly written CSS. Definitely the positives outweigh the negatives, though.
Also, I was at sassconf in NYC and I believe it was mentioned that the w3c has started to agree with some of the concepts introduced with sass (one big one is variables).
My big problem with SASS is so many people use it to make the most horrendous overly specific selectors in the universe, plus the agencies who use it NEVER hand over the build files, and can’t understand when you complain about their awful 230KB stylesheet that you *know* should be around 30KB.
I must confess, before working on the `so you think you can dance` website, I didn’t really see the use of pre-processed css. When you are dealing with a huge project, that’s when you can really appreciate the power of mixins and variables etc..
Now I set all my projects up with SaSS or Stylus
Great! I was looking forward to this book coming out for ages and I’m glad this post reminded me to buy it.
The book is as great as I’d hoped and although I thought I knew quite a bit about SASS I learned loads – taking tips from the book and integrating them into my workflow pretty much straight away!
Thanks Dan 😀
Nice article. I prefer LESS over SASS because of the syntax considerations you mentioned regarding CSS adoption of more complex concepts.
Most developers work with a designer at some point. LESS feels and reads more like CSS than SASS (in my opinion), so I have found it is an easier hill to climb for non-programming designers, and LESS.js allows for fast prototyping prior to final production processing.
Also the statement ‘CSS is hard’ is true but misleading — ‘CSS’ isn’t hard, the differences in the way browsers implement it makes it hard. If all browser’s behaved exactly the same, it wouldn’t be nearly as difficult, and that isn’t the language designer’s fault. And neither SASS nor LESS fix that problem (though mix-ins can make multi-browser CSS statements less tedious).
Pre-processors are the automatic transmissions of the web development world. There is no reason that you can’t learn to code manually, and possibly write much cleaner code, with slightly more effort. But it’s “harder”. It’s scary to think that there are many people who will now likely never learn good clean CSS, because they will just start using a pre-processor, and churn out unnecessarily heavy style-sheets. If you have good CSS chops and you decide to use a pre-processor, that’s your prerogative. On the other hand, this mania that seems to suggest that using a pre-processor inherently makes you a “better” dev is ridiculous. Having used both SASS and LESS for different projects, I can honestly say I find little to no productivity increase over when I just code in CSS.
Waiting to see the next article so far read through many articles about SASS & LESS, tried to use them but didn’t find very useful. As Chis also said, Little to no productivity increase….
Spot on!
CSS preprocessors are a wonderful thing; indeed, the next stage of CSS evolution. [Fear not the command-line!] Would love to buy Dan’s little pink book, but I’m already on the LESS bandwagon. Will A Book Apart come out with a LESS edition sometime?
You can avoid the command line for sass if you really want to.
Although I’m entirely comfortable with command line shenanigans, doing pretty much all my git stuff via command line, when it comes to sass (or less), I use a little app by alphapixels, called PrePos.
I find it more effective than running a watcher in the command line.
I bought a while back CSS3 for web designers by Dan Cederholm. I must say I really enjoyed it. I believe his new book on SAAS will be a killer too!
I really love to use it, better forever. Bring the word of variable,conditional and other to CSS. Easy to use, easy to maintain…
Why don’t use SCSS today ^^?
(My feeling after 5 months used it^^)
Good to see this. One of your books helped me years ago master CSS, and this past year I’ve fully embraced using SASS as well. It IS complex the deeper you go, but for the examples you’ve listed, I think it’s easy for users to make the switch.
I’ve been a LESSCSS user for some time. It’s been a real change in efficiency, organization, code reducing, modularization… and fun. I gave SASS a try. (Yeah. I had a @ extend hangover too. Its like tequila. I don’t remember what had happened but was a great party…) Don’t know why the SASS hype started so loud these days. Maybe something good will come with that. Maybe CSS4 will come with SASS and batteries included. Just don’t know. But will be good for us anyway. I just hope it become funnier and simple as LESSCSS. Write @ mixin and @ include for every mixin is boring.
Just like Dan it took me a while to start using a preprocessor—now it is a key part of my workflow (I use LiveReload).
If you are moving to SASS, I would suggest you check out the .sass syntax. It does take some getting used to (compared to the more common .scss syntax), but the readability and simplicity offered by .sass is helpful—especially when working on complex projects.
Great article!
I felt the same way, and hopefully in the future the question will become “Why not SASS?”.
Thanks
The Thesis 2.X framework has had a CSS preprocessor built into it. It also lets you separate reusable code in the skin editor from custom CSS. Both use the same set of variables.
I have found it very efficient to make CSS changes only to the custom CSS, leaving the basic skin alone.
I use Less for two reasons:
1) It can run in the browser (no compile step in development)
2) The compiler can run in node. The whole Ruby stack is way to slow.
Also I’m not a CSS framework developer, so I don’t need the extra features that Sass admittedly has. Apparently everybody else seems to have no problem with the slowness of ruby. At CSSConf.eu I was the only non-Sass user in the room.
Some Frameworks allow you to build HTML5 and CSS3 projects fast and most importantly responsively. I tried Foundation5 and ended up banging my head against the wall(desk) and just used the simplest partsof the framework instead of trying to learn all the “push-” and complicated alteration markup. Ditto for YII and Twitter. Too much to learn when I can just type in what I want.
Instead I now build my own framework with either fixed divs or percentage divs; or both then apply a Margin Master Style Sheet that I wrote which eliminates learning ANY other markup that compensates for a framework being over complex—demoizing itself by over-design. Margin Master I hope catches on because it is the simplest and easiest way to create space between elements and divs without having to learn any [one elses] syntax. “marg-” is the class tag and (for example) marg-t1 is: margin: [top 1em]… it goes on forever with marg-b (bottom), marg-l (left) and several center and text alignment syntax starndards (hope to be… catch on standards).
Webpage CSS would include reset, style, margins and custom. No java, no learning just l1 thru 9 or t1 thru9 etc. You have to see it to believe in it. http://sourceforge.net/projects/marginsmaster/ Larry Judd tradesouthwest.com
Sorry but I’m not jumping on this “believer” train. I don’t find CSS hard, and I’m not impressed with your opening examples. In your first examples, you say “wouldn’t it be great if you could just change the color in one place…” but no, I don’t think that would be great at all. That means I lose the flexibility of changing things later and having the header color be something else. I’d rather just use CSS classes and IDs the way they were meant to be used. It works, it’s easy, it’s efficient, and it doesn’t take me long to write regular old CSS. Maybe if I found it “hard” like you do then I might look at adding a crutch into the mix.
And what about maintenance? If developer A used SASS, but developer B needs to make a change. Well, sucks to be developer B if he/she is unfamiliar with SASS or *doesn’t like it* or something else.
I think all these people who like SASS are not crafting uniquely designed websites or web apps, but rather making cookie-cut template sites that all look the same except for a few colour changes here and there. Enter SASS.
You can keep it, thanks. I do my programming in JS. CSS has a lot of things going for it these days in modern browsers, please don’t ruin it by insisting that developers believe in your pre-processing evangelism. If you’re happy using it, go for it. But it’s not REQUIRED for good quality CSS coding.
Hey, I think Sass or Less are OK nevertheless it takes a sub-process to compile the code and previous steps just to have some more useful functions. I already used Sass once or twice but in my opinion all the fuss needed to setup it up doesn’t pay the output. I see Sass/Less as a potential evolution of CSS just like Jquery was and is for Javascript although the gain on the last one is way more substantial and we just need a link to the CDN, easy!
Although I don’t believe in the technology I enjoyed the article,
Best regards, Dessain Saraiva.
Like others say,
Sass or other CSS compilers can be an extra step in your workflow. It does adding a little more to the learning curve when you start using Sass functions, mixins and other goodies.
However, if you take the time to set up a good file structure (using _partials) to organize your styling rules; you are bound to not only enjoy using technology like Sass, you’ll depend on it.
I’ve been pushing myself lately to write very lean css. The examples provided at the top would be producing serious bloat. To write lean css requires good mockups that take reusable elements into account, and good understanding of css. Bad mockups produce big bloat. I’m also a big advocate of mixing elements in the markup, that way you keep your css rules very lean, and your css file very clean. Mixing css classes in the mockup is sort of the same as sass does in css itself. It is harder to write lean css in using preprocessors because preprocessors add another layer of obstruction, and you have to think harder to write good css.
Secondly, I never understood why changing color in sass is such a good example of the power of sass:
$brand-color: #fc3;
a {color: $brand-color;}
To me this above sass code is not even a good example of lean css output. What you’d end up is bunch of css rules where the same color is repeated over and over again. I’m sure there is a leaner way of writing this same example in sass without producing bloat. Someone please chime in.
Look, if you need to change color after you’ve coded the site, you have a serious communication problem somewhere in your design process. That’s what mockups are for. I thought you’re supposed to agree with your client on color, and all the details of your design before you jump into sass. But apparently a lot of folks change color after color. Why? I do not know.
SASS has its uses, as do other preprocessors, but my preferred one is Stylus. Very easy to setup, allows you to write bracket-less rules, and extend on the existing regular stylesheets.
Thanks for the Article. Is your book on Safari books online? I can’t find it. Also, do you know of other books, videos on sass. Currently there appears to be only 3 books on sass on safari books online, and the rest refer to sass in single chapters. Thanks!
I just learned CSS (yet to start my first project ). Would you advise me to use learn SASS now or play more with CSS in a few projects and then learn SASS ?
All the pro-developers/designers kindly pour in your thoughts.
The greatest strength of SASS (or any pre-processor) for me is how nicely it plays with version control software. Having multiple front-end developers working on a project without css merge conflicts (because everyone’s working on isolated scss file) saves a lot of headaches. Likewise, tracking changes over time is a lot easier when the files are broken up in to modules and properly commented.
You stated…
I read this and I had to comment on this first. I’m going to force myself to read the rest of this article, but this threw me off… I can change the value in one place and have it trickle down through my entire site…. with a class! Based on the description you gave, with a color, or changing a block of styles… I can do this with a class.
At first glance, I’m not sure what the real benefit of SASS is… I could use it, but I’m more motivated to write something I know. Again, I’ll keep reading, but this almost made me leave the page.
I appreciate with this and if you have some more information please share it with me. This is really good work from your side. I strongly recommend you keep doing this kind of work, and I hope you will have many entries or more. http://khelomcx.com/
this is really good work form your site