If you are unfamiliar with Sass:
I recommend you check out our very own Brian Krall’s introductory post on Sass and Compass before reading on.
Imagine this scenario:
Your little brother’s birthday is coming up, and you’ve decided to make him his own custom screen-printed t-shirt. Thankfully, due to your extensive art education, you know how to print impeccable shirts in the preferred method. You come up with your design, do the color separations, burn the screens, and print a fantastic 3-color masterpiece. On the big day, you hand your brother his gift, and he decides that he wants the letters to be red instead of white. He goes to his room, grabs a big red Sharpie, and haphazardly scribbles all over your handiwork.
Unhappy with the result, he hands you back the shirt and tells you that it doesn’t look right, and that you need to fix it. Little brothers are the worst.
For better or for worse, making the choice to commit to a particular craft ultimately means that you will have to retain a certain bit of continuity once it leaves your hands, whether the recipient is an awful hypothetical sibling, or an otherwise wonderful client that might not know or care about the craft involved in the delivered result.
For the better part of the last year, Duo has been using Sass as our CSS preprocessor of choice, to great effect. We love its efficiencies, its structure, and how it motivates us to be better-organized coders. Despite our love affair, our front end team is running into a dilemma that has plagued back end developers for years: how do we manage beautifully crafted code with a client who is going to want to tinker, and even more difficult, what happens when the client breaks our toys and hands us back the pieces and asks us to fix it?
There is so little about this particular question that the best intel I was able to dig up is an interesting twitter conversation between designer Scott Kellum and front end dev, Patrick Fulton:
At this point, we’ve only had to do a few handoffs with sites coded in Sass, but in our experiences so far, Scott’s point seems to be the exception, rather than the rule. Clients that have the inclination to tinker are likely versed in basic CSS, and may be averse to learning a new technology that is like CSS but might not seem ‘worth it’ for them to learn when they can just bypass the process and get into the compiled files, which can cause major headaches in the future. Although Duo is in the process of working out this balance ourselves, we have some general recommendations for how to approach this issue.