Sass isn't for me | Hacker News Reader

Sass isn't for me

nathanborror.com

24 pointswebology31 comments

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).

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

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.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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?

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 ;-)

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.

Don't ever make assumptions about what I do or how I design. You're an ignorant sod for making said assumptions in an attempt to defend SASS.

Do you have any reasonable supporting argument for that statement?

This reads close to: "iPhone takes it way too far. Phones are for calling people, not surfing the web and running applications"

Sorry, it's not. The iPhone brought major improvements and some really awesome ideas.

SASS brings nothing to the table that hasn't already been done and it fails to even do the standard things better.

SASS was a great idea for writing CSS easier. Now it's just a crappy programming language that works with CSS. CSS needs to be made easier, HTML needs to be made easier. Making it a Turning Certified language is no way to do that.

Sometimes you need a hammer. Most of the time you don't need a hammer with six gauges and a penis pump. CSS is one of those times.

Why?

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.

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".

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.

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.

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?

> Well the bad part about Sass is that designers won't work with it.

Wrong. There are many designers who love sass and they kick some serious ass. Actually, EVERY designer with whom I've sat down with and shown them sass and compass has fallen in love with it.

> At least with CSS, everyone is speaking the same language.

By this logic every programmer should still be programming in COBOL and FORTRAN. But the reality is that every decade or so, a new language comes along and moves the industry in a new direction. Well guess how old CSS is? CSS is getting serious scrutiny now because there are so many programmers doing front end implementation now. I've used CSS. In fact, I'm great at CSS, but we can do better and be more efficient.

I have no problem with SASS's basic concepts but I'm a supporter of using whatever language you feel comfortable with to write web pages. I think HTML blows donkey shit.

In this case SASS doesn't need that. Every major and most minor languages can do variables and loops. Wouldn't it be more intelligent to focus on getting SASS as a universal way for programming languages to work with styling instead of making SASS a programming language?

At some point you have to stop and think about what's better for the community.

A niche programming language that brings very little to the table much less anything done well is not good for the community.

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

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

Like this: http://github.com/chriseppstein/compass/tree/master/lib/comp...

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.

Reply on news.ycombinator.com