5 ms·
Sass isn't for me
- webology 17y agoAlthough I disagree with most of Nathan's points, there is a really good discussion going on.
- pkulak 17y agoCompile CSS 3 down to CSS 2? Is this guy on crack? How do you compile border-radius or drop shadow down?
- chriseppstein 17y agoLike this: http://github.com/chriseppstein/compass/tree/master/lib/compass/frameworks/compass/stylesheets/compass/css3/ 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.
- ThinkWriteMute 17y agoSASS 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 17y agoThose 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 17y agoWell 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 17y agoAnecdotally, 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 17y agoThat'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?
- chriseppstein 17y ago> 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.
- randrews 17y agoI 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 17y agoSASS takes it way too far. CSS is for styling, it's not a programming language and it never should be.
- chriseppstein 17y agoThat 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 17y agoSome 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 17y agox86 assembly language is similarly universal. Nobody writes in it.
- wvenable 17y agoCSS 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.
- dasil003 17y agoThis 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 17y agoYou're not what we call an "early adopter".