HAML certainly has it’s benefits, and it’s abstraction isn’t that unfamiliar to those use to HTML and CSS. It’s pretty quick to pick-up. My biggest problem however is the inevitable switching between HTML and HAML. Debugging something in the browser for example, I see the HTML. If I then want to bring up the source HAML file for that HTML, I need to do more mental mapping of what I’ve seen in the browser, to the what I’m seeing in my code editor. Another problem is that I often whip up my concepts and designs in plain HTML and CSS, before I even go near Ruby. It’s always been a simple matter of copy and paste the HTML, and then substitute any dummy data with actual dynamic data (e.g ).

I fear that with HAML, the time I may save in writing HAML will be lost by the initial conversion from HTML to HAML. It is also another thing to learn for developers that wish to collaborate with you. It’s for this reason I’m not sold on HAML. I’m going to stick with ERB for now I think.

The catalyst in my case was switching to vim and not having a great set of HTML editing plugins yet. With HAML, vanilla vi editing is terrifically efficient. For SASS the wins are more obvious, but at the same time, modern CSS3 with its browser-specific attributes requirement compounds the value.

If you’ve ever used haml for a large project or with big template files, you’ll discover that it is very fragile, not just because of indentation, though that’s an issue, but because you’re one level away from your templates, so that’s another layer of abstraction to keep in everyone’s head. For the same reason I avoid builder templates, because erb is far closer to the final output, and after a while the added abstraction of builder syntax just starts to get in the way. In addition, using haml and thus more ruby in templates just encourages you to put more code in the template, which is never a good idea. If your erb is full of garbage code, fix it – your templates should be mostly html, not code.

If you don’t work with other people it’s fine to use HAML, and good luck to you, but don’t claim it’s the one true way, as this really comes down to preference. Trying to convert a project which has several contributors and/or designers etc involved is a waste of everyone’s time, unless everyone is agreed from the start that it’s a great idea.

What’s really won me over to trying out HAML & SASS is the idea of cutting out the context shifting. Reducing the barrier between my markup structure and the styles for that markup is really attractive. Thanks for putting down your thoughts on these tools.

Having forced myself to give it a go for a couple of weeks though I now find myself hugely reluctant to go back. Its quicker to type, the semantic indentation that used to make me so cross now feels so obvious, it’s easier to read, easier to isolate sections of code and move them about and the output is superb, perfect indentation that you don’t get with ERB.

You can also mix it with ERB so you don’t have to do a whole project at once.

Let me first acknowledge that I am very aware of the theory of “Cognitive Dissonance” in Psychology, and that I am also aware that without context I would assume such to refer to exactly that. However you fail to observe that “Cognitive Dissonance” has entered into the English language as “cognitive dissonance” purely as a result of the popularisation of this theory and has been current in this fashion only since the nineteen-forties.

However this taking on of a new meaning does not in anyway preclude M.E. Patterson for using the term in the way in which it would have been used before this theory was formalised and in the sense of the two words being used: cognitive, pertaining to cognition; and dissonance, pertaining to incongruity. As a programmer (with a background in linguistics), I at no point thought that he was referring to the theory in Psychology but took it to mean, in the sense that the author has since clarified, a discord in the mind resulting from two contradictory (in terms of mental processes arising from different implementation paradigms) approaches to describing what is essentially the same; the document structure.

To jump on his back for what you perceive to be an incorrect usage of this term betrays an ignorance of linguistic register, i.e. that some terms have different meanings in different contexts. To alert readers that this term is not confined to psychology alone functions in opposite fashion to the behaviour you say will occur, namely that reading this blog will not make anyone “dumber” by seeing the term used in this context, but rather, those coming from a knowledge of psychology, will in fact be alerted to the fact that these two words have a broader application than their narrow application within that field. This I would hope should make someone more intelligent, not less so.

Shame on you; not for your ignorance, but for your zeal in propagating your ignorance to others.

I don’t believe in blog post revisionism. That is, what I posted is what I posted. The commentor rightly took me to task for misusing a cognitive psychology term, and I accepted that criticism in the comments, albeit with a response that was a little tongue-in-cheek (really, guys, this is a programming blog… does anyone except me to be an expert on psychology?). But I don’t believe in going back and changing my original post text. The post and the comments are inextricably linked. Changing the post is tantamount to revising history to make oneself look smarter, and I hate blogs that do that. I wrote what I wrote. The comments thread annotates that. Deal with it.