You failed to quote the rest of his premise: "CoffeeScript guards against common coding mistakes, like ensuring variables are properly declared within lexical scope."
I don't use HAML so I don't know, but does it provide features like that?
In a manner of speaking. Some things are difficult to do in HAML, which happen to be things you shouldn't be doing anyway.
For example, I don't know how to write multi-line Ruby code (with the exception of function calls) in HAML. I wouldn't be surprised if there is a way, but you can't just drop it in like you can with ERB. This means that if you need multiple lines of Ruby, you move the code a more appropriate area (model, helper, controller, etc).
You do multi-line Ruby the same way you do multi-line javascript or css:
:ruby
# ruby code goes here
:css
body { of-css: styles; }
:javascript
alert('and JS here');
":something" defines a language filter in Haml, and it reads the whole indented block through that filter, and sometimes wraps it in a tag (:css and :javascript get free %style and %script tags). Also available are :plain, :sass, :textile, :markdown, etc. http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#fi...
HAML completely eliminates the "Oops, where did I forget to close that div?" problem. It also punishes you a bit for putting too much business logic in your templates, which pushes you towards well-factored views with your business logic in helpers, and your actual markup in the templates, resulting in cleaner and easier-to-maintain templates. From a debugging standpoint, HAML can output perfectly-indented HTML for your whole document, so templating needs don't end up screwing up your indentation, resulting in extremely readable output if you need it.
I think it's completely disingenuous to rag on HAML while praising Coffeescript. They both provide the same effective result, but for two different products. They eliminate the annoying, slow, cumbersome parts of working in their counterparts.
Comments
You failed to quote the rest of his premise: "CoffeeScript guards against common coding mistakes, like ensuring variables are properly declared within lexical scope."
I don't use HAML so I don't know, but does it provide features like that?
HAML indention also prevents common coding mistakes like poorly placed closing tags
In a manner of speaking. Some things are difficult to do in HAML, which happen to be things you shouldn't be doing anyway.
For example, I don't know how to write multi-line Ruby code (with the exception of function calls) in HAML. I wouldn't be surprised if there is a way, but you can't just drop it in like you can with ERB. This means that if you need multiple lines of Ruby, you move the code a more appropriate area (model, helper, controller, etc).
You do multi-line Ruby the same way you do multi-line javascript or css:
":something" defines a language filter in Haml, and it reads the whole indented block through that filter, and sometimes wraps it in a tag (:css and :javascript get free %style and %script tags). Also available are :plain, :sass, :textile, :markdown, etc. http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#fi...Or, if you're a bit masochistic, you can use the multiline character: "|" http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#mu...
FYI, you can wrap any line of Ruby at a comma, provided there is one.
HAML completely eliminates the "Oops, where did I forget to close that div?" problem. It also punishes you a bit for putting too much business logic in your templates, which pushes you towards well-factored views with your business logic in helpers, and your actual markup in the templates, resulting in cleaner and easier-to-maintain templates. From a debugging standpoint, HAML can output perfectly-indented HTML for your whole document, so templating needs don't end up screwing up your indentation, resulting in extremely readable output if you need it.
I think it's completely disingenuous to rag on HAML while praising Coffeescript. They both provide the same effective result, but for two different products. They eliminate the annoying, slow, cumbersome parts of working in their counterparts.