I would agree with you if you were talking simply about Markdown, but it seems you don't understand the point of HAML. Markdown is a complex syntax that loosely translates to half of HTML. It's good for user-input, because it's designed to be written like users already write stylistic formatting when the result will be plain ASCII, but it's not HTML.
HAML is HTML—it's a one-to-one conversion—but it's simpler and more concise to write. It's what HTML should be: no closing brackets, no line noise, and simple syntax to access DOM-relevant attributes (class and id). If I had the option of immediately converting all HTML worldwide into HAML, and all HTML parsers into HAML parsers, I'd sign up in a second.
Also, I don't need to see the raw HTML any more, because that's not the point: it's like looking at machine language instead of assembler. They're equivalent, so why read it the painful way? When debugging a page layout in HTML, I actually find it more useful to convert it into HAML first.
Having had to use and debug HAML before, I absolutely hate it. I would argue that it is more difficult to read HAML and leads to buggier code. Missing what amounts to two spaces can break your layout without you realizing it until much later.
This is especially true if you use a CSS framework where you have lots of nested elements with several classes each.
After looking into HAML again (I've looked at it before, and I'll admit, I clearly missed the point), I'll concede.
It does make HTML look significantly cleaner since it seems to run along the same general concept as Python (indents are blocks), and that is something I can support.
I'll be looking into giving it a try next time I have a good chance to...I appreciate the explanation.
are you absolutely sure about that? No edge cases around the whitespace?
"it's like looking at machine language instead of assembler."
That would only be true if HTML tags were specified by number.
"They're equivalent, so why read it the painful way?"
HAML is more readable only in the sense that it forces a certain indentation structure on you. If you are working with well-formatted HTML than there is not much benefit there. Overall, when HTML gets deeply nested, I'd rather see the ending tag.
As far as writing is concerned, yeah, HAML is a big win if you don't know how to use your editor. I solved that problem 10 years ago and I didn't have to switch to an format no one understands to do it. Let me put it this way:
If HAML had the same tooling support as HTML, and if other people were as likely to understand it, and if it didn't require a compilation step, then the benefits of HAML would be clearcut. As it stands, HAML just doesn't offer anything compelling to me (SASS comes closer).
HAML is HTML—it's a one-to-one conversion—but it's simpler and more concise to write. It's what HTML should be: no closing brackets, no line noise, and simple syntax to access DOM-relevant attributes (class and id). If I had the option of immediately converting all HTML worldwide into HAML, and all HTML parsers into HAML parsers, I'd sign up in a second.
Also, I don't need to see the raw HTML any more, because that's not the point: it's like looking at machine language instead of assembler. They're equivalent, so why read it the painful way? When debugging a page layout in HTML, I actually find it more useful to convert it into HAML first.