My biggest qualm with Sass is that it introduces a speed bump in my workflow compared to using plain CSS. This is due to the fact that I can use tools like CSS Edit to create, edit, and verify my CSS all at the same time. If these tools also supported Sass I'd be all set.
Although it doesn't satisfy your 'no speed bump' test, you could still generate css files with CSSEdit and then convert them to Sass with css2sass. Certainly inelegant, but it could cut it.
Also, just out of curiosity, why do you use CSSEdit? I'm guessing you probably write your HTML or Haml markup with Textmate and not Dreamweaver, right? Why do something different with CSS?
CSS Edit gives me instant feedback on my changes. It's not always easy to know how changes to your CSS will display. You have to think about all the rules that are in play, as well as the defaults of a given browser.
HTML is much easier. You're just dealing with structure, so it's much easier to comprehend.
We've tried to get the CSSEdit folks to support Sass, but so far they haven't been interested. I think the best way to get that is to have more users say they want it.
I would guess that such a change would be too big to be economically viable. Sass would require a rewrite of all the parsing code, and a redesign of the GUI CSS editor. Unless Sass gains a considerable market share among Mac users, I doubt it'll happen.
You're better off trying to convince them to include the necessary hooks in Espresso, if they add CSSEdit-style functionality to it.
This is an odd meme, and not really accurate. Yes, Sass has a few control structures that are not meant to be used in day-to-day stylesheet coding. But the language is wholly geared towards creating stylesheets, and every feature was added with that in mind. It doesn't contain any programming features for the sake of having programming features.
I'm pretty sure it is Turning-Complete, and it's something they were heralding a few weeks back. Their goal is to be a programming language.
Wikipedia: After its initial versions, Nathan Weizenbaum and Chris Eppstein have continued to extend Sass with SassScript, a Turing Complete scripting language used in Sass files.
You're replying to the guy who writes Sass. He's right. It's not actually turing complete, but it could be made so with a relatively minor change.
And I'm the guy who invented most of the programming facilities of Sass and I'll tell you, they're not very good programming tools -- but they're enough to make some really great stylesheets.
In order to be Turing-complete, Sass would have to have some way of reading and writing arbitrary amounts of memory. Since it has neither anonymous functions nor any sort of data structures, it can only read and write from pre-declared variables.
Actually, I think you've got something interesting mixed into that comparison: assembler. SASS/HAML aren't like a high-level programming language like C or Ruby, because there's really just not that much translation going on. They're more like assembler: a one-to-one mapping of machine language that makes it easier to read and work with.
Sass (not Haml) allows you to work at a significantly higher level than CSS. The parallel in programming languages might be Forth: the basics translate directly, but using the abstractions provided by the language you can make it work at a much higher level.
In the case of Sass, abstraction is primarily provided by mixins and functions. Compass (http://compass-style.org) provides an excellent example of using these to write CSS at a much higher level.
Thanks for the compliment, though the idea of "definitive" anything typically makes me bristle.
.
I stand by what I wrote, but I wrote it mostly because enough people kept asking me why I didn't care for Haml, and I'm sort of bad at keeping my mouth shut.
>I view static indentation as I do most forms of static typing: needlessly restricting in an attempt to solve problems that don’t come up much in Real Life code but make for nice pedantic rants about “But what if?”.
As a happy Python user, I absolutely resent going to languages that require code block delimiters. Since I consistently indent anyway (and have done so since long before I ever discovered Python), it just feels like pointless duplication of effort to indent and delimit using curly braces or do ... end or whatever.
Significant whitespace may not be for everyone, but there's no case to be made that it's punitive.
"Significant whitespace may not be for everyone, but there's no case to be made that it's punitive."
There's a worthwhile difference between Haml's "must be this distance, exactly" approach and the offside rule of Haskell. That I cannot add some extra indentation for clarity or ease of reading in Haml is wrong.
BTW, is there an auto-format plugin for vi that will automatically set/adjust the indentation of Haml if it is misaligned?
As far as know, it's up to the typist to ensure that each item lines up exactly so, which is extra work (i.e. punitive), but perhaps I've just failed to find the right plugin.
That post sounds like the happy driver of a 1986 Honda Civic complaining about unecessary gadgets like fuel injection, power steering and antilock brakes.
If you're a one-man team who does the whole stack on your own personal project, something like HAML might be for you.
However I have to say, in 10+ years of working on multi-person, multi-discipline web teams, there isn't one to whom i could see having recommending something like HAML.
Just raises too high a bar for designers and front-end developers (ie CSS/HTML specialists), for whom learning a new language is actually a fairly big deal.
SASS seems to be enough like CSS that it wouldn't necessarily pose a comparable problem to the designer brain. I could see designers grokking its basic features like variables and seeing them as a thing that gave them more power.
If my experience is representative, though, configuration might be SASS' achilles heel right now. Really gave it the ol' college try and my SASS files never QUITE seemed to compile how and when i expected. Compass was even worse in that regard for me. I am getting old though, so maybe i've just lost a step or two :) Anyone else have similar experiences?
I think you aren't giving designers enough credit. They're generally quite smart folks, and tend to pick up Haml and Sass just as quickly as programmers.
I'm sad that you found Sass's configuration difficult. What in particular did you have a hard time figuring out how to do? We're always interested in improving the documentation and UI.
A lot of IDEs/text editors can autocomplete HTML closing tags, so I find the comparison based on characters moot.
I'll admit it might make things easier to navigate with the eyes. But on the other hand it seems to abstract something that's really not that complicated to begin with.
A lot of IDEs/text editors can autocomplete HTML closing tags was my initial response to HAML. I was dragged into using HAML, and I'm glad/frustrated for it. Glad, because by the time I finished that project I realized how much faster/easier it made things; frustrated, because the following day I started another (rather large) job in which HAML wasn't an option. It's hard to put into words why I found HAML superior to HTML. A really poor way of explaining it is http://en.wikipedia.org/wiki/I_know_it_when_I_see_it - just replace see with do.
As for SASS, maybe I'll feel the same way after I jump in, but the idea of adding a layer of abstraction to CSS seems like trouble - IE 6/7/8 is trouble enough.
Sass can actually help quite a bit with dealing with the IEs. Compass (http://compass-style.org) has a bunch of mixins that are fully cross-browser and make short work of a lot of compatibility issues.
It is so. much. faster. to write. I've never been able to articulate why, but, in particular, if you do interaction by lighting up DOM elements by class in jQuery, Haml is like having a language designed to lay out UIs.
Iunno, 99% of my HTML writing is copy & pasting. I just write one thing and usually just copy and paste it around. The bottleneck is in fixing CSS and cross-browser display, not really the speed of HTML coding.
That being said, if your HTML development style is based around writing everything then I can see how it would be faster. But for me I use autocomplete+copy&paste, and then usually a lot of other stuff I (embarrassingly) google and then copy from examples.
I started writing an abstraction system... Then I realized about 5%, maybe even less, of my development time is actually in the HTML. Even for front end most of it is in CSS/javascript after you get the HTML structure ready. Copy and pasting is because much of that structure is repeated, but still there isn't much copy and pasting on the whole.
I've only been using HAML & SASS for around a month and I'm by no means an expert. I've found that using mixins saves me a lot of time. At the top of my stylesheets I lay out bits that I repeat a lot such as:
This comes up every time people talk about Haml. It's a red herring. You're crazy if you ask your designer to work in Haml. There are few enough excellent designers to begin with; consider yourself lucky to get semantic markup out of them, let alone Haml and Sass.
On every professional project I've worked with, we were given markup and assets from designers, and then expected to integrate them ourselves. If you're lucky enough to have a designer on staff, train them in Sass. Otherwise, the process of converting HTML to Haml and CSS to Sass isn't any harder than converting mockup HTML to templates.
On the opposite side, if you just need a refresh or a facelift, you give them the HTML and CSS that Haml and Sass generate. It's nicer looking than ad hoc markup already.
This is the key point. You save time working with Haml and Sass if your designers can use them, edit them, etc.
I am longing to get to a point where the designers I work with can be expected to write templates using mustache or django template language...
Ideally the designer can check out a submodule of the project and commit ongoing UI enhancements by simply modifying mustache/django templates that they wrote in the first place.
This could easily be implemented by using a static site generator to populate the templates with static data so that the designer could check his/her work before committing.
With Haml you end up translating the whole mess over and over again, and if you decide to make a big change to HTML/CSS you are spending lots of time redoing the HAML/Sass.
The other key thing to realize is that CSS is an extremely expressive spec when used properly I really don't think that the small bit of conciseness offered by Sass is worth adding another layer...
CSS, although a very cool and powerful language, leaves a lot to be desired in one key area: abstraction. Not coincidentally, this is the area that Sass is best at. Chris Eppstein has an excellent blog post (http://chriseppstein.github.com/blog/2009/09/20/why-styleshe...) explaining why abstraction in stylesheets matters.
I agree with tptacek that this is a red herring, but I disagree about why. Maybe I've been lucky, but all the designers I've interacted with are plenty good enough to get Haml and (especially) Sass. And most of these designers have liked them.
The semantics of Haml and Sass are identical to those of HTML and CSS. The extensions they add are generally clear to anyone familiar with the base languages. And Haml has the great benefit of making HTML be written like CSS, which is much more comfortable to designers.
A developer that can't understand Haml is a no-hire, whether or not you buy into Haml. Designers don't need to work in Haml and Sass; Haml and Sass are developer tools.
It seriously takes like 10 minutes to learn the HTML -> HAML and CSS -> SASS mapping. The semantics are virtually identical, only the syntax is different.
Haml and Sass are elegant tools for simplifying view code, and I never, ever use ERB or CSS anymore if I can avoid it.