[LRUG] HAML

[Vahagn Hayrapetyan]

>
> So: the main thing I noticed about HAML, to begin with, is that it was
> clearly a tool written for programmers (rather than dedicated
> client-side developers) to write HTML. Which, you know, sets alarm
> bells ringing.
>

It would appear that HAML being a tool by programmers, for programmers isn't
a bad thing after all. The most basic thing a programmer has to deal with is
syntax, and that must be 100% correct for the program to run at all. This
isn't true of markup code however - we have all seen sites that use invalid
markup but the browser still displays them. So if the programmer mentality
that syntax cannot be less than 100% valid can be enforced in the field of
markup via tools such as HAML, that's a valuable thing IMO.

(But then again, I guess using HAML doesn't actually prevent one from
writing invalid markup, does it?)

If you don't write decent HTML, HAML won't help. If you do, it
> will.
>

/ Vahagn


On Mon, Dec 14, 2009 at 6:11 PM, Tom Armitage <tom at infovore.org> wrote:

> On Thu, Dec 10, 2009 at 3:22 PM, Anthony Green <Anthony.Green at bbc.co.uk>
> wrote:
> >> Isn't it time you all gave in and used haml?  Come on - you know it
> >> makes sense....
> >
> > As a Semantic HTML Web Standardista I also presumed it could only lead to
> > more terrible HTML code.
>
> So was I, and am now convinced this just isn't true.
>
> So: the main thing I noticed about HAML, to begin with, is that it was
> clearly a tool written for programmers (rather than dedicated
> client-side developers) to write HTML. Which, you know, sets alarm
> bells ringing.
>
> However: if you know HTML, and write good HTML, there's nothing to
> stop you using HAML to write good HTML. Very good HTML, in fact. The
> few decent HAML sites I've worked on are behind firewalls, I'm afraid,
> otherwise I'd send you a link.
>
> You do have to do a small amount of translation, but there are some
> good trade-offs:
> - HAML spits out valid (X)HTML automatically. Either it throws an
> error because you've made a mistake, or it generates and closes an
> element. Yes, I usually write valid code; HAML ensures I do.
> - HAML spits out beautifully formatted code. This is really, really
> useful; I hate debugging sites based on a "view source" view that's a
> mess, caused by partials and ERB templates with their own indentations
> all playing havoc with one another. This is avoidable, but HAML
> doesn't require you to take great lengths; it spits out nicely
> formatted code, which makes debugging fine.
>
> Honestly, as a decent client-side dev, I've been able to implement
> complex, fiddly designs in HAML with no trouble; I've been able to
> write decent, semantic haml and avoid divitis with no problem; I've
> managed to majorly cut down repetition and lines-of-code written, and
> yet the templates are clear, understandable, and well-maintained.
>
> I am always wary of abstractions, and as with all abstractions, the
> main point is: make sure you understand the thing being abstracted
> first. If you don't write decent HTML, HAML won't help. If you do, it
> will. This is the main problem it has (and, that because it's all a
> bit strange, it's favoured by back-end devs, rather than client-side
> bods). But I'm a total convert, if only for my wrists' sake.
>
> (Still not convinced on SASS yet, in part because it's *too* similar
> to CSS. That's my inner csd coming out).
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20091214/93dd9964/attachment-0003.html>