There are some more serious issues with Haml, Sass etc. that I wonder aren't brought up more frequently. One is simply tool support, in Firebug or Chrome developer tools I see HTML/CSS/Javascript not Haml/Sass/CoffeeScript. As soon as I start using any of those "add-on" languages, I cannot refer to the line numbers Firebug gives me for the various CSS classes, nor to the line numbers a JavaScript debugger gives me, in fact I have to debug something more or less different to what I wrote. In the end I cannot just know Haml/Sass/CoffeeScript, I have to know both HTML and HAML, both CSS and Sass, both CoffeeScript and JavaScript and switch between those languages frequently. Unless you have a very small / very simple codebase, I think this makes things not simpler, but more complex.
> As soon as I start using any of those "add-on" languages, I cannot refer to the line numbers [...]
I can't say I disagree, but I don't think this is a serious impediment. Though Sass and CoffeeScript have recently pushed this sort of referential opacity into CSS and JavaScript, it's been an "issue" in HTML markup for decades: As soon as you introduce any kind of templating or conditional logic, you're handing the browser generated content that doesn't map directly to line numbers of files on disk.
In that vein, how is Haml different from ERB or Jinja2? The latter may superficially resemble HTML, but they aren't HTML. An even stronger parallel could be drawn from Less or Sass's scss syntax.
Well I'm your case this makes sense. Speaking for SASS and LESS here, you know you can get a few other apps that'll compile and help you debug your SCSS styles. There's CodeKit, LESS.app, and now Crunch. These tools take you to the line in your SCSS file that's causing issues instead of referring to the compiled CSS.
I mean, hear what you mean but I think the level of annoyance or love for these tools depends on your workflow. Personally, I use LESS along with CodeKit (I used to use LESS.app) and I usually don't have those problems. The times that I do run into a line number reference problem I'm usually able to find the offending code quite easily as the line in my abstraction language file (LESS, Coffeescript, whatever) is usually only a few lines lower than what the debugger tells me. In addition, if the debugging tools give me just a short snippet of the offending code then I can pretty easily remember where it is regardless of how large the file is.
In the end though I think this is all about a person's workflow. Some workflows are better suited to these abstraction languages and their compilers/debuggers than others. Personal preference, I guess, is what it comes down to.
Comments
There are some more serious issues with Haml, Sass etc. that I wonder aren't brought up more frequently. One is simply tool support, in Firebug or Chrome developer tools I see HTML/CSS/Javascript not Haml/Sass/CoffeeScript. As soon as I start using any of those "add-on" languages, I cannot refer to the line numbers Firebug gives me for the various CSS classes, nor to the line numbers a JavaScript debugger gives me, in fact I have to debug something more or less different to what I wrote. In the end I cannot just know Haml/Sass/CoffeeScript, I have to know both HTML and HAML, both CSS and Sass, both CoffeeScript and JavaScript and switch between those languages frequently. Unless you have a very small / very simple codebase, I think this makes things not simpler, but more complex.
> As soon as I start using any of those "add-on" languages, I cannot refer to the line numbers [...]
I can't say I disagree, but I don't think this is a serious impediment. Though Sass and CoffeeScript have recently pushed this sort of referential opacity into CSS and JavaScript, it's been an "issue" in HTML markup for decades: As soon as you introduce any kind of templating or conditional logic, you're handing the browser generated content that doesn't map directly to line numbers of files on disk.
In that vein, how is Haml different from ERB or Jinja2? The latter may superficially resemble HTML, but they aren't HTML. An even stronger parallel could be drawn from Less or Sass's scss syntax.
Well I'm your case this makes sense. Speaking for SASS and LESS here, you know you can get a few other apps that'll compile and help you debug your SCSS styles. There's CodeKit, LESS.app, and now Crunch. These tools take you to the line in your SCSS file that's causing issues instead of referring to the compiled CSS.
I mean, hear what you mean but I think the level of annoyance or love for these tools depends on your workflow. Personally, I use LESS along with CodeKit (I used to use LESS.app) and I usually don't have those problems. The times that I do run into a line number reference problem I'm usually able to find the offending code quite easily as the line in my abstraction language file (LESS, Coffeescript, whatever) is usually only a few lines lower than what the debugger tells me. In addition, if the debugging tools give me just a short snippet of the offending code then I can pretty easily remember where it is regardless of how large the file is.
In the end though I think this is all about a person's workflow. Some workflows are better suited to these abstraction languages and their compilers/debuggers than others. Personal preference, I guess, is what it comes down to.