Har­ry Roberts is right. Sass is noth­ing more than a work-around for a work-around that CSS au­thors that know how to write prop­er CSS in the first place don't need. But we can't just blame the HTML mon­keys.

HTML and CSS thrive in an en­vi­ron­ment where every­thing re­volves around se­man­tics. In a work­flow where the con­tent is cre­at­ed first and more or less se­man­tic markup is added lat­er and fi­nal­ly that markup is used for styling, it all comes to­geth­er nat­u­ral­ly as in­tend­ed. But with to­day's fo­cus on cut­ting costs and thus reusable frame­works the process is of­ten com­plete­ly re­versed. In that sit­u­a­tion a CSS au­thor has to cre­ate a style sheet be­fore any­thing is known about the con­tent and the se­man­tics that will be forced in it. The only thing the au­thor then can come up with is a very elab­o­rate gen­er­al pur­pose col­lec­tion of rules and se­lec­tors that should be able to han­dle about any con­tent in an or­thog­o­nal and di­ag­o­nal way at the same time. Of course that will re­sult in an in­cred­i­ble mess of CSS for which you'll need all the help you can get to stay sane han­dling it. It's like de­sign­ing a data­mod­el in which you aren't al­lowed to do any nor­mal­iza­tion be­cause it has to be so gener­ic you can't tell what data is of the same type.

If you know what con­tent you're han­dling you can in a data­mod­el for ex­am­ple eas­i­ly tell sup­pli­ers, em­ploy­ers and clients all have some­thing that re­sem­bles an ad­dress, so you only need one gener­ic ad­dress type in your mod­el. CSS cre­at­ed in the re­verse work­flow can't tell yet if it boils down to the same type and has to stick with three seper­ate de­f­i­n­i­tions. Of course the nest­ing fea­ture of Sass comes in handy to de­fine that mess.

Vari­ables are some­thing that is in­deed miss­ing in CSS. But not in the way Sass aims to fix it. The prac­ti­cal use and na­ture of CSS of­ten lead to hav­ing to de­fine the same col­or val­ue to vary­ing prop­er­ties. If it's just about the same prop­er­ty it's pos­si­ble to gath­er all the se­lec­tors and de­fine the prop­er­ty in a sin­gle rule, but you can't link for ex­am­ple a bor­der-col­or and a back­ground-col­or so chang­ing a sin­gle val­ue changes both. What Sass adds be­yond that is a work-around for when the HTML mon­key isn't al­lowed to put ad­di­tion­al class names in the markup. Once you have de­fined the name of the vari­able in a mean­ing­ful way the same ef­fect can be achieved by us­ing that vari­able as an ex­tra class­name and add it to the se­lec­tors. The same is valid for mix­ins: Once you know why a sin­gle mix­in is used for sev­er­al se­lec­tors, the prop­er so­lu­tion is to fix it by adding the se­man­tics to the project.

But be­cause in the re­verse work­flow it's not pos­si­ble to give the vari­ables and mix­ins se­man­tic names, adding class­names breaks out of the il­lu­sion of seper­a­tion of con­tent and pre­sen­ta­tion. In the nor­mal work­flow you'll no­tice the se­man­tic re­la­tion be­tween el­e­ments first, and have no prob­lem adding those se­man­tics to the markup in the form of a class­name and hap­pi­ly use that as a hook for style in­for­ma­tion. The re­verse work­flow pre­vents that log­ic.

Vari­ables and mix­ins in CSS are of­ten a sign of la­tent se­man­tics. If the same de­sign is used for mul­ti­ple el­e­ments, a CSS au­thor should in­quire if there is a se­man­tic rea­son­ing be­hind it or the el­e­ments have dif­fer­ent se­man­tics and have just the same de­sign. In the re­verse work­flow this is fu­tile be­cause the de­sign­er just de­signs some gener­ic box­es and the CSS au­thor just styles some DIVs with­out car­ing about se­man­tics. And if CSS isn't based on se­man­tics it's all a bit point­less any­way. Then you get main­te­nance is­sues like a client wants to have pub­lic hol­i­days a dif­fer­ent col­or and the HTML mon­key wasn't even aware there were dates at­tached to his per­fect­ly styled gener­ic box­es. Often the only way out is then to blame some­one and tell the client it's im­pos­si­ble and screw ex­pe­ri­ence de­sign. You know clients who can't af­ford a cus­tom so­lu­tion can't af­ford ex­pe­ri­ence de­sign tests any­way.

What Sass is good at is mak­ing it eas­i­er to do by hand what tools like Dreamweaver are even bet­ter at. There is no point in writ­ing CSS by hand if that means you've thrown all the added val­ue of what that meant away and try to com­bine the brand val­ue of hand cod­ed CSS with the ease of gener­ic tools. No­body is in­ter­est­ed in a hand built Volk­swa­gen.