Hacker News Reader

Comment by endtwist | Hacker News Reader

Oh please. The time you spend learning HAML or Markdown (and all their potential intricacies) could be better spent learning to write clean HTML. I'm sure that both of those "alternatives" have their own quirks that must be worked around, not to mention the fact that you don't know exactly what HTML the parsers will spit out (yes, you can learn the output, I suppose, but why?).

I can see these tools being useful in certain circumstances, such as a way to provide HTML-esque markup somewhere where you don't want to bother cleaning up someone else's potentially malicious HTML (a wiki, a comment form, etc.). However, for building actual websites, just do it the right way.

Sure, these alternatives are nice in that you can avoid the scary HTML, but in the end it is all HTML anyway -- so why not learn it from the start and produce better code than what a parser will spit out based on your abstraction?

View on HN

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.

Amen brother! Preach it. Sing out the good word across the land. Over the hill-tops and down to the valley below.

Everybody who knows HTML knows HAML. Actually learning HAML would have still given you time to write a paragraph complaining about it.

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.

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.

"it's a one-to-one conversion"

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).

You are completely missing the point of HAML.

HAML is for people who know and use raw HTML, but who would rather not spend time on typing closing tags and all other syntatic sugar and line noise. HAML allows writing pages using leaner and more concise markup, all the while improving its readability.

> rather not spend time on typing closing tags

Isn't that what Emacs is for?

Vim!

Although I must admit you've got a point there, it's a bit like Atwood's indentation piece yesterday, why bother fussing over that when your editor can sort it for you?

The point is that HTML is a standard format that many tools and people are familiar with. HAML is not. While HAML might be more succinct, there is a tradeoff being made that is probably not appropriate for all situations.

I can agree with that, I wouldn't use a code-based markup generator simply because I couldn't see how you'd add design-based containers and things in there. Seems to eb good at producing semantic content markup, but not for full pages.

Markdown is for writing content. Content creators shouldn't need to write their content (blogs, news, whatever) in HTML. Markdown is for that and only that.

I also like it for readmes on github, FWIW.

Right. Any (those I can think of at least) type of content that doesn't require specialized formatting (math symbols, etc) like READMEs, blogs, journals, CMS content, etc.

Reply on news.ycombinator.com