> quite obviously inexperienced in using Haskell
I'm using Haskell for only four months now, I'd be worried if it weren't obvious.Besides, it's not as bad as it looks.
+++ just concatenates two HTML fragments
<< puts something under a HTML element
the ! [...] defines attributes for a HTML element
Pretty clear, but I guess to each his own.
Here's the equivalent HAML:
#gallery
.screenshots
ul
li
a{"href" => "view.fcgi?file=#{first}"}
HAML is super clean, and there's essentially no redundant syntax; in other words, if you type something, it's because it's necessary. There's no fat.non-idiomatic hamlet isn't far from that haml snippet (note you would never put bits of urls in the template as strings, instead you provide a url rendering function which converts the @{} bits into url strings):
<#gallery
<.screenshots
<ul
<li
<a href=@{View first}
idiomatic hamlet is much more focused on being a cleaner html for designers than it is trying to be a haml clone.I agree. Considering that you can assign 'id' and 'class' through the main syntax, I don't think it's too bad. Attribute values are Ruby strings, so the quotes work for me. With Ruby 1.9 you should, in theory, be able to use the new improved hash syntax:
a{href: "/ding"}
...but I don't know if HAML has implemented it.Edit: HAML actually supports a different, simpler syntax for attributes:
%a(href="/ding")
> idiomatic hamlet is much more focused on being a cleaner html for designers than it is trying to be a haml clone.I know that some companies work that way. We let our designers learn HAML (and SASS) instead. That way they can contribute to the projects as first-class citizens. HAML is simple enough that a designer can even work with conditionals and loops.
The two most common template libraries are Heist[1] and Hamlet[2]. Heist uses Rails/Django-style external template files, while Hamlet embeds markup directly into the Haskell source code using quasiquotation.
[1] http://snapframework.com/docs/tutorials/heist
[2] http://www.yesodweb.com/book/templates
Even if one wanted to represent markup as Haskell types, there's no reason it needs to be as ugly as in that example. A really basic version might be: