#chris-eppstein

position:unique

Featured Post

Psst. I want to let you in on a little secret about Sass. Let's keep
this between you and me: Sass doesn't have any original ideas in it. I
think this is actually the key to Sass's success. Original ideas are
hard to understand. Every single Sass feature is simply a formalization
of what developers had already been doing. Initially, Sass features
simplified what developers were doing in CSS, or in templating languages
on top of CSS, and simply put a nice abstraction on top of existing
patterns that we saw in use every day.

As Sass has progressed, we have turned that eye of simplification onto
Sass itself. Recently, some Sass features have been added to simplify
the Sass code we saw people writing every day and the language's
expressiveness has continued to increase.

As Sass has become more powerful, we are starting to reach a very
interesting point in the language's maturity: Sass users are now able to
express in Sass syntax complex behavior for things that they would have
used to only imagine as language features.

As you might expect, when implementing a complex behavioral pattern in
Sass, the code is going to be complicated. Recently, I read a blog post
calling out someone blogging about a Sass pattern they've found useful
and saying that they had gone "too far" and created code that is
"unmaintainable". But if it's done right, that complexity is hidden
behind a strong abstraction. So the question is, how far is too far?
When has a Sass developer jumped the shark and made something that is
unintelligible and unmaintainable?

I'll grant you, sometimes I read a Sass user's code and I shake my head
and say to myself:

I see a pattern as new Sass features are introduced or when people first
discover the language (this is true for other technologies as well). We
want to try them out! And in doing so, we tend to reach a bit too far.
Maybe we nest too deep. Maybe we make too many mixins or extend things
that should not have been extended... because we can. And then we
experience this and realize it's not better and then we find the happy
medium of when and where to use a particular feature.

I will grant you that concepts implemented in pure Sass might not feel
as natural as if they were in Sass itself. In fact, the limitations of
the Sass syntax might make an otherwise good idea, bad in practice. But
I always appreciate the attempt to find a simplification that works.
Every community needs these risk-taking, crazy people who are willing to
buck trends and try things that may actually be terrible ideas. Because
the only way to have a great idea is to have lots of ideas and for us to
share them, try them and critique them. Bad ideas will wither and die.
But the good ideas will spread because they will make people's code
better.

I would encourage people who have tried to do something in your Sass
project only to discover that it turned out to be a net negative, you
need to undo that mistake. Don't leave bad ideas in your project -- but
also don't be afraid to try them! And if you write something
complicated, by all means test
it and document it.

I for one am really happy to see Sass reach this point where the
language can self-host new ideas. As one of the language's designers,
seeing things actually working for people makes a very strong case for
what should become part of Sass's core feature set. Or maybe they point
towards features that make it easier to extend Sass's syntax in a more
natural way. I'm not entirely sure yet.

Finally, when you look at a some concept that causes you to scratch your
head, you can actually read the implemenation. And when you do, If your
reaction is "Whoa, that's too much!" instead of "Cool, I can figure this
out!" Then, I humbly submit that you are being short-sighted. The
underlying implementation of everything you do every day when working
on the web is so incredibly complex. The fact that a little bit of that
complexity is accessible to you instead being neatly tucked away across
a language barrier, doesn't make things inherently less maintainable.

In fact, it may make them more maintainable. Strong abstractions are
stable and don't need updates very often, so even if the code is
complex, that's ok. As long as it presents a coherent, well-tested API,
you will have a codebase that is usually more maintainable one the
whole. And in the rare case where you find a bug in Sass code, instead
of in something in Sass itself, you'll be able to actually dig in and
maybe even fix it yourself instead of just filing a bug and hoping for a
fix.

About Me

I am an open source hacker and stylesheet architect at LinkedIn.
I live in San Jose, California with my wife and daughter.

Open Source

I'm the creator of Compass, a stylesheet authoring framework
and I'm on the core team of
Sass — the stylesheet syntax upon which Compass is built.
I maintain about a dozen less well known ruby libraries and rails plugins on
github,
and am an active contributor of patches to the many open source projects that I use.