5 ms·

Thoughts on Haml

17 points by villageidiot 17y ago

villageidiot 17y ago
This post is a negative critique of Haml which points out that it is not an improvement over HTML - it makes working with designers more cumbersome for one thing. A somewhat different viewpoint from a StackOverflow user: http://stackoverflow.com/questions/93540/your-attitude-to-haml/430325#430325 http://stackoverflow.com/questions/93540/your-attitude-to-ha...
- melvinram 17y ago
  That persons code doesn't do HAML justice. I converted an ERB file to HAML. A quick glance shows it to be simpler... even though it's mostly the same code: http://pastie.org/private/n8ipfrkxlremo4jwtxiww http://pastie.org/private/n8ipfrkxlremo4jwtxiww More detailed response is here: http://railsnotes.com/395-response-to-thoughts-on-haml/ http://railsnotes.com/395-response-to-thoughts-on-haml/
  - deleted 17y ago
    [deleted]
nixme 17y ago
I'd say his main points boil down to poor tooling and creating a solution for a problem that doesn't really exist... except that many of us do see issues with existing templating options and Haml+Sass works really well. I will concede that it can cause friction with designers though.
carbon8 17y ago
Eh, different strokes for different folks. My only major criticism of Haml is that it makes me actively adverse to how incredibly verbose HTML is, which probably isn't a good trait for a web developer.
- melvinram 17y ago
  Yea, I know what you mean. I found a cool tool that lets me do all my prototyping in haml before having to do any real Rails coding: http://github.com/jlong/serve/ http://github.com/jlong/serve/
jdminhbg 17y ago
I don't understand the criticism that it's for people who don't understand HTML. How could you even use it if you didn't know HTML?
- villageidiot 17y ago
  I thought his point was that people who like it tend to be newbies to web development who are not able to make an informed critical judgment about its merits because they don't know enough of HTML to begin with - they learn HAML by seeing its output without understanding the HTML that underlies it. But I agree that this seems like a weak argument. I can't imagine working in web development without understanding HTML.
bradgessler 17y ago
James is right on about where HAML falls short; but thats not HAML's problem, its more of a preference. I will be the first to say that HAML is no appropriate for everything. Here is how I apply various templating engines in my Rails projects: HAML - Great for application markup (as opposed to document markup... see ERB below) for a number of reasons. (1) application markup tends to be heavy in javascript where you need a clean DOM. HAML reduces the chance of screwing up the DOM and makes it easier to look at during development. (2) Lots of conditionals in the view and I'm too lazy to factor them out into partials or helpers. Sometimes its just easier to express if/then and loops in HAML than it is in ERB... slightly less markup. ERB - Document/content markup. If I have big docs with lots of links and paragraphs, but nothing to heavy going on thats dynamic/conditional, ERB is the easiest way to go. Mix 'n' match! Then you can have the best of both worlds!
- intranation 17y ago
  I have to say, as a professional web developer, that I've never found that "application markup tends to be heavy in javascript", or that I've "(screwed) up the DOM". HTML isn't particularly difficult, although things like HAML might prove that doing it well without a helper abstraction is difficult. Code management (breaking things up into appropriate templates and fragments) trumps things like HAML for ease of use and clean separation every time.
_pius 17y ago
This was me until about the 3rd time I played around with Haml. Then it occurred to me how much noise I got rid of by using it, after which I was hooked. Jquery + Haml is a very close impedance match and a real pleasure to use for development.
- villageidiot 17y ago
  "Jquery + Haml is a very close impedance match" - is that another way of saying they're a good combo or is there more to it than that?
  - _pius 17y ago
    It's actually more specific than that. Take the following Haml that defines a div with an id of "foo" along with a span with class "bar" and content "Hello World": #foo %span.bar Hello World If I wanted to hide those elements, I'd write the following jQuery in a separate file: $('#foo').hide(); $('span.bar').hide(); That's really powerful stuff. The Haml syntax for defining elements looks exactly like the CSS3-style selectors used by jQuery, so much so that I often cut and paste my Haml markup into my javascript files.
    - villageidiot 17y ago
      Glad I asked. I had no idea there was such a close relationship.
dougp 17y ago
Web designers often send me half heartedly formated html that is full of repetitive nested structures that I do not understand. When trying to turn it into a collection of partials I have inevitably destroyed some important tag. Everything breaks and I have to start over. Turning it into haml has two benefits. I can visualize the structure of repeating elements so I have a better idea what to break into partials and I will never forget a closing tag which causes everything to break in some horrific way.
zacharypinter 17y ago
I agree with the author on editor support for closing tags. I often find myself noticing something is wrong when I tell the editor (emacs) to auto-indent everything and it doesn't look the way I expect it to. I also find ERB to be quite simple and straightforward. That said, I'm quite interested in using Sass.
melvinram 17y ago
I use real code to show how HAML kicks ERB-ass: http://railsnotes.com/395-response-to-thoughts-on-haml http://railsnotes.com/395-response-to-thoughts-on-haml
- deleted 17y ago
  [deleted]
raganwald 17y ago
I like James' perspectives, but the "If programming X irritates you, get better tooling" argument reminds me of another programming language, Java.

17 points by villageidiot 17y ago

This post is a negative critique of Haml which points out that it is not an improvement over HTML - it makes working with designers more cumbersome for one thing. A somewhat different viewpoint from a StackOverflow user: http://stackoverflow.com/questions/93540/your-attitude-to-haml/430325#430325 http://stackoverflow.com/questions/93540/your-attitude-to-ha...

melvinram 17y ago
That persons code doesn't do HAML justice. I converted an ERB file to HAML. A quick glance shows it to be simpler... even though it's mostly the same code: http://pastie.org/private/n8ipfrkxlremo4jwtxiww http://pastie.org/private/n8ipfrkxlremo4jwtxiww More detailed response is here: http://railsnotes.com/395-response-to-thoughts-on-haml/ http://railsnotes.com/395-response-to-thoughts-on-haml/
- deleted 17y ago
  [deleted]

nixme 17y ago

I'd say his main points boil down to poor tooling and creating a solution for a problem that doesn't really exist... except that many of us do see issues with existing templating options and Haml+Sass works really well. I will concede that it can cause friction with designers though.

carbon8 17y ago

Eh, different strokes for different folks. My only major criticism of Haml is that it makes me actively adverse to how incredibly verbose HTML is, which probably isn't a good trait for a web developer.

melvinram 17y ago
Yea, I know what you mean. I found a cool tool that lets me do all my prototyping in haml before having to do any real Rails coding: http://github.com/jlong/serve/ http://github.com/jlong/serve/

jdminhbg 17y ago

I don't understand the criticism that it's for people who don't understand HTML. How could you even use it if you didn't know HTML?

villageidiot 17y ago
I thought his point was that people who like it tend to be newbies to web development who are not able to make an informed critical judgment about its merits because they don't know enough of HTML to begin with - they learn HAML by seeing its output without understanding the HTML that underlies it. But I agree that this seems like a weak argument. I can't imagine working in web development without understanding HTML.

bradgessler 17y ago

James is right on about where HAML falls short; but thats not HAML's problem, its more of a preference. I will be the first to say that HAML is no appropriate for everything. Here is how I apply various templating engines in my Rails projects: HAML - Great for application markup (as opposed to document markup... see ERB below) for a number of reasons. (1) application markup tends to be heavy in javascript where you need a clean DOM. HAML reduces the chance of screwing up the DOM and makes it easier to look at during development. (2) Lots of conditionals in the view and I'm too lazy to factor them out into partials or helpers. Sometimes its just easier to express if/then and loops in HAML than it is in ERB... slightly less markup. ERB - Document/content markup. If I have big docs with lots of links and paragraphs, but nothing to heavy going on thats dynamic/conditional, ERB is the easiest way to go. Mix 'n' match! Then you can have the best of both worlds!

intranation 17y ago
I have to say, as a professional web developer, that I've never found that "application markup tends to be heavy in javascript", or that I've "(screwed) up the DOM". HTML isn't particularly difficult, although things like HAML might prove that doing it well without a helper abstraction is difficult. Code management (breaking things up into appropriate templates and fragments) trumps things like HAML for ease of use and clean separation every time.

_pius 17y ago

This was me until about the 3rd time I played around with Haml. Then it occurred to me how much noise I got rid of by using it, after which I was hooked. Jquery + Haml is a very close impedance match and a real pleasure to use for development.

villageidiot 17y ago
"Jquery + Haml is a very close impedance match" - is that another way of saying they're a good combo or is there more to it than that?
- _pius 17y ago
  It's actually more specific than that. Take the following Haml that defines a div with an id of "foo" along with a span with class "bar" and content "Hello World": #foo %span.bar Hello World If I wanted to hide those elements, I'd write the following jQuery in a separate file: $('#foo').hide(); $('span.bar').hide(); That's really powerful stuff. The Haml syntax for defining elements looks exactly like the CSS3-style selectors used by jQuery, so much so that I often cut and paste my Haml markup into my javascript files.
  - villageidiot 17y ago
    Glad I asked. I had no idea there was such a close relationship.

dougp 17y ago

Web designers often send me half heartedly formated html that is full of repetitive nested structures that I do not understand. When trying to turn it into a collection of partials I have inevitably destroyed some important tag. Everything breaks and I have to start over. Turning it into haml has two benefits. I can visualize the structure of repeating elements so I have a better idea what to break into partials and I will never forget a closing tag which causes everything to break in some horrific way.

zacharypinter 17y ago

I agree with the author on editor support for closing tags. I often find myself noticing something is wrong when I tell the editor (emacs) to auto-indent everything and it doesn't look the way I expect it to. I also find ERB to be quite simple and straightforward. That said, I'm quite interested in using Sass.

melvinram 17y ago

I use real code to show how HAML kicks ERB-ass: http://railsnotes.com/395-response-to-thoughts-on-haml http://railsnotes.com/395-response-to-thoughts-on-haml

deleted 17y ago
[deleted]

raganwald 17y ago

I like James' perspectives, but the "If programming X irritates you, get better tooling" argument reminds me of another programming language, Java.