

Sass isn't for me - webology
http://nathanborror.com/posts/2009/nov/30/sass-isnt-me/

======
dasil003
This is a fantastic post and discussion. I've had many a debate about this,
and I tend to come down on Jeff Croft's side.

For the record, I'm more of a developer than a designer, but design was my
first love, and I've been wrangling HTML by hand for 15 years now, and CSS for
10.

I see the value of Sass. CSS has some really obvious pain points when it comes
to things like standardizing color palettes and certain types of design
constructs. It doesn't take much to add a lot of value to CSS, which I think
Sass does admirably.

But my problem really boils down to the ubiquity of HTML and CSS. Everyone
knows it. Windows, Mac, .NET, LAMP, it doesn't matter, everyone uses it. All
the tools support it, and all computers have a web browser where you can view
the raw files directly.

As soon as you add a pre-processor like Sass that simplicity is gone. You can
no longer work with _any_ designer, you need one that has the pre-processor
set up and is comfortable with the syntax. In a pinch you can pass the
processed CSS to a designer, but then you have a versioning problem, and you
are likely creating lots of busy work for yourself.

You face a similar issue with tools. They all support CSS, and some of them
have some really cool features that can only come from having a userbase of a
million developers battle testing it over years. It's not just text editors
I'm talking about here, but debuggers, spiders, javascript libraries, and who
knows what else.

So the real issue with any kind of CSS preprocessor is that by choosing it you
are limiting your ability to leverage a whole ecosystem of talent and tools.
Ideally a really great pre-processor could someday get enough traction to see
itself become a standard, but that is not something we can hope for any time
soon.

Is the tradeoff worth it?

For me I default to saying no, because I already have learned how to deal with
CSS and it's an insignificant pain point to me compared to all the other
things that go into building a great web product.

However in the general case costs vary. If your canonical design already lives
in a framework like Rails then Sass doesn't really incur any additional
tooling cost, because anybody working on the design already has to have the
framework running locally anyway. However there are many team structures and
workflows where HTML/CSS mockups ideally can stand alone.

I would love to join a team working with Sass, but I don't think I would
choose it for a greenfield project (yet).

~~~
chriseppstein
You're not what we call an "early adopter".

~~~
dasil003
Sure I am. When I said 10 years on CSS I wasn't kidding. Do you know how few
web designers were using CSS in 1999? Also, I started using Rails in early
2005, almost a year before 1.0.

It's sort of insulting to minimize my points by suggesting that I just don't
like new stuff.

~~~
chriseppstein
I'm sorry if you took offense. Your arguments are valid ones -- they are borne
of wisdom over time that makes you more risk averse. Early adopters throw this
kind of caution to the wind because they see promise and are looking for a
competitive edge. Instead of waiting for a tool to mature, they help it
mature. It's not an insult that you've matured, you should take it as a kind
of a compliment.

But the 10 years ago you wouldn't have taken your advice. 10 years ago CSS was
not ubiquitous. There were not good tools. The ecosystem was just getting
going. And yet somehow the tradeoff was worth it for you.

Technical designers learn sass quickly. They like it and so the tools will
follow. The ecosystem will grow. Already Sass experience is considered a plus
in job reqs for many forward-thinking startups. Sass and Compass will mature
in the next few years, and you're objections will fall by the way side and a
few years after that, instead of having a competetive advantage, you'll be at
a competitive disadvantage by not using something like it.

I don't know if Sass and Compass will ultimately be the tools of choice for
generating CSS, but I'm certain that there will be tools like them.

~~~
dasil003
_Instead of waiting for a tool to mature, they help it mature. It's not an
insult that you've matured, you should take it as a kind of a compliment._

If that's not a back-handed compliment I don't know what is.

Here's the thing though, I'm not risk averse. I am the first one to jump into
a nascent project and throw down code. The problem here is the cost benefit
just isn't there for me yet. I feel I have more competitive advantage to gain
by working on greater pain points (for me personally) like lack of
continuations in Rails, or even something a lot more ambitious like writing a
usable web framework in Haskell in order to gain the advantages of pure
functional programming.

In other words, just because I don't a big competitive advantage in your
project doesn't mean I'm not an early adopter.

------
randrews
I don't see how this is any different from any other Blub paradox: these
people don't see what's useful about the features Sass adds to CSS, because
they think in CSS, and think the syntax is funny-looking, so they don't want
to bother.

~~~
ThinkWriteMute
SASS takes it way too far. CSS is for styling, it's not a programming language
and it never should be.

~~~
chriseppstein
That what CSS is, but that doesn't mean that's the only way to style a
website. Use your imagination and stop accepting the constraints that have
been placed on you by those who got here first.

~~~
wvenable
Some constraints are good. If it's not for constraints, you'd have cats
marrying dogs and so on. Putting programming logic in a stylesheet language is
asking for more complexity, not less.

I agree with the author. CSS is universal. SASS is entirely different language
with far less "speakers" and far less support. It may be superior to CSS, but
that's only part of the equation.

~~~
tptacek
x86 assembly language is similarly universal. Nobody writes in it.

~~~
wvenable
CSS is closer to C than x86 (and C is _more_ universal) Are you going to say
nobody writes in that, too?

Edit: I meant universal in that everyone reads/writes it -- not that it's the
lowest level. Yes, nobody writes x86 so it's not similarly universal. C is
pretty universal. Even if you code in Java, C#, or PHP you've still got a lot
of C heritage there.

~~~
tptacek
I have no idea what your point is. People write in Java, Ruby, Lisp,
Javascript, and any of 50 other languages to avoid writing bare-metal C, too.

~~~
wvenable
I'm not sure what your point is! Your original comment about x86 doesn't even
make sense -- most people don't know x86 assembler! However, _all_ web
designers know CSS. Nearly all web developers know CSS. That's what makes it
universal! It's not about how low-level it is.

We recently had to fire a design team and are in the process of moving to a
different team. If all the styles were in SASS, I'd have a much bigger
problem.

Even something like LessCSS has a much smaller learning curve because it looks
like CSS. You can use it much more minimally (using only variables, for
example) and get a small benefit with a small learning curve. Think of how
many of those 50 other languages look like C.

~~~
tptacek
It really seems like you don't understand how Sass works, or at least haven't
actually run it. If anything, Sass layers _more_ gracefully than C does over
x86, since compiler-generated x86 is incomprehensible, and Sass-generated CSS
is probably more readable than what a typical designer produces. Sass also
promotes CSS best practices, in part by automating them, and in part by
providing syntactic sugar for them.

If your designers can't grok Sass, you do what every professional team using
template languages has always done; you back-and-forth with the designer in
CSS/HTML, and you convert final comps to templates. Designers by and large
don't speak Haml, Erb, Clearsilver, or Cheetarah (or Mum-raah or whatever
Django calls it) either.

~~~
wvenable
The designers produce the CSS, I don't. In most cases, they use their fancy
tools to produce it. If they're not using SASS, what's the advantage to me?
Why would I convert their CSS to SASS to get the same result in the end?

Templates are a different story -- that's where the design and the
functionality meet. I do convert the final comps to templates and if necessary
the templates back into static code to repeat the process (rarely necessary,
but it happens). This is a necessary evil. Why would I want to perpetuate that
evil in CSS as well?

~~~
chriseppstein
You know what's funny: I know of several design firms that are using sass to
generate their css and they deliver the generated CSS to their client without
ever telling them that they used sass to make their development process
faster.

If they had given you their Sass code, you would be empowered to make design
changes much more easily that you could have with CSS. If I were you, I'd be
demanding that my designers use it ;-)

~~~
tptacek
Funny thing about Hacker News, where the guy who wrote Compass gets modded
down below the guy criticizing Sass without ever having once used it.

------
ThinkWriteMute
SASS is bad because it got addicted. Starts with math, leads to variables,
then someone suggests recursion and iteration. Suddenly you've got a really
crappy programming language instead of a useful tool designed to make bullshit
easier.

~~~
chriseppstein
Those aspects of the syntax are not there because you're supposed to use them
to design a website. They are they because frameworks need a very basic level
of programming in order to build simple abstractions. You're supposed to use
selectors, properties, and mixins to design your website.

Occasionally, you might see an opportunity to make your own mixins to simplify
your site and make your design easier to maintain. When you do, you'll be glad
that the mechanisms for abstraction are there for you too, not hidden away
from the "designers who have to be protected from code".

~~~
catch23
Well the bad part about Sass is that designers won't work with it. Unless you
work on a team of 3 and you've got a programmer that does the CSS, there's no
problem, but I think most companies that have 8 or 9 people on staff probably
has a full time designer that may or may not like sass.

At least with CSS, everyone is speaking the same language. Also, most big
websites end up having CSS in other places other than a central location
driven by sass. You'll probably end up having some element level css, maybe a
few scattered in various jquery plugins, or one-line jquery hacks for
modifying css classes or changing colors etc.

~~~
qhoxie
Anecdotally, that is not true. I work with a reasonably sized team on a large
website. We are collaborating with a well-respected design firm and our teams
are both using Sass/Compass. Thus far, I would say it has been a great
success.

Variables, arithmetical, and mixin abstractions make the team integration much
smoother. All this, and the learning curve is incredibly small.

~~~
chriseppstein
That's awesome. I'd love to hear more about this! Could you please blog or
send a posting to the compass mailing list describing your experience in
greater detail?

------
webology
Although I disagree with most of Nathan's points, there is a really good
discussion going on.

------
pkulak
Compile CSS 3 down to CSS 2? Is this guy on crack? How do you compile border-
radius or drop shadow down?

~~~
chriseppstein
Like this:
[http://github.com/chriseppstein/compass/tree/master/lib/comp...](http://github.com/chriseppstein/compass/tree/master/lib/compass/frameworks/compass/stylesheets/compass/css3/)

Many of the CSS3 attributes are here today in the form of vendor prefixes. But
there are subtle vendor differences and you have to duplicate each property
several times. It's tedious.

But compass provides a consistent API across all the browsers and it's
available today.

