2008 / December 23rd/ HAML isn’t about designers complaining
There are a few very vocal enthusiasts when concerning HAML (Yes, I still believe almost no one uses it, it’s just an extremely vocal minority). Ask them the biggest resistance to using it and they probably use some kind of cop out excuse concerning “our designers are too stubborn/dumb to try it.” That’s such crap.
Your decisions in your domain
As a programmer, how do you feel when the head of marketing comes over to you and says, “I was reading this article today, and I really think we should consider moving to J2EE/Struts — it’s clearly the future.”
You’re probably be offended. Who the hell does this guy think he is, telling me what language I should be programming in? He doesn’t program, he doesn’t understand anything — he’s just read some damn article and come down with a decision you should be making.
But that’s exactly what developers force-feeding HAML are doing to their designers.
HTML is my friend
I wrote my first lines of HTML in 1997. That may be just over 10 years, but more importantly — it’s almost half of my life. I’ve literally grown up with it. Over the past four years, I’ve written more HTML than I ever thought possible. I really like HTML.
It’s stayed around in it’s current form because it’s actually a really good language (spec? format? whatever). Most prominent UI frameworks include something that replicates HTML (be it XAML in WPF or MXML in Flex). Don’t mess with a good thing.
Out of all the communities on the planet, I would think the Ruby community (a community birthed from a language that is inherently slower, but more enjoyable to use) would be the last ones to force a language on designers that designer’s don’t like.
If you speak Spanish, don’t learn Chinese when traveling to Spain
My main beef with HAML is that it’s completely unnecessary. In order to write HAML, you have to have written HTML (either in your head or in code). Then you write HAML. Which outputs HTML. This is absurd.
I can fully understand people enjoying the syntax of HAML over HTML, even if I may not agree with it. But at the end of the day when you’re creating layouts and debugging display issues: you have to know HTML. You’re certainly not seeing HAML in the browser.
With ERB, I write HTML in my views and I get HTML in the output. Anyone who knows HTML can look at my views and understand what is going on, because the output is the same as the input. There’s no magical fairy interpreter. It’s simple. It’s elegant. It’s not clever.
Think of the children
I know the Ruby community loves it’s cleverness (even if they won’t say so in public), but perhaps think of the impact of your cleverness. Personally, I don’t see enough advantages in HAML to warrant it’s cleverness cost. Maybe your designers don’t either.
If you think it’s taking you too long to code HTML, the solution is to learn HTML better. Writing HAML won’t teach you HTML.
34 Comments
Warpspire is the place that web professional Kyle Neath writes about the web. More →
Hot Topics This Month
-
2007 / Why I don’t use CSS Frameworks
85 comments
-
2008 / Top reasons your CSS columns are messed up
217 comments
-
2009 / Having fun with the Lighthouse API
8 comments
-
2009 / Quick & Dirty Referral Tracking
11 comments
-
2009 / Optimizing asset bundling and serving with Rails
11 comments
Feeds / Syndication
Choose your preferred method of syndication. All feeds are full-posts & ad-free. All feeds are protected under copyright and may not be redistributed without permission.
The Network
All my little projects that I leave scattered around the web. Some for profit, all for fun.
December 23rd | #
I am a front end guy so it’s not like I am a programmer trying to force it down anyone. I’ve been working on a project that we decided to use it and I have found it to be pretty enjoyable to write. I think it is better to just write your code in HAML and not write it in HTML first. I found this out early after it taking forever to write it then translate it. I find it easier to debug because you have less problems with missing close tags or nested problems because of the indentation requirements. I also like how it outputs so beautifully in the source code but that has no effect on anything. I don’t think reading HAML is much different then reading html except for the fact there are no angle brackets and the way the attributes are listed.
I do think it should be a mutual decision between your front-end developer and software engineer, no one likes to be told that they have to do something in a way for the mere fact that it helps the engineer code faster. I personally like HAML but if I didn’t want to do it then that should be my decision as the front-end developer.
December 23rd | #
Amen bro! The same goes for the folks who like to write Ruby in order to generate JavaScript code. But I suppose there’s a reason why choice is good. There are lots of Rubyists out there that don’t like or know JavaScript. Anyway, I’m glad you piped up about HAML… I’ve always felt the same way.
December 23rd | #
Cleverness if programming is almost always a mistake. HAML seems like it was an attempt to fix something that wasn’t broken.
If you have standards for how your front end code should be formatted and written, there shouldn’t be any problem with indentation, missing closing tags, etc. that take much time to debug.
The fact that it ends up outputting HTML just seems like an unnecessary extra step to me when writing HTML is something any middle schooler could do.
December 23rd | #
You hit the nail on the head: HAML is a complete total and utter waste of time, un-needed, un-wanted, solves non-existent problems in a way no front end designer/developer would want to use anyway.
And with credentials like that I’m actually pretty surprised it isn’t a new W3C spec. Arf arf!
December 23rd | #
Yeah, I mean, why learn CSS when we have tables and font tags. Why learn any server side scripting languages when we can hard code everything.
In all seriousness, you make at least one good point, no one wants to be forced to learn something they care nothing about. But to disregard some very substantial benefits because of this one reason is a bit short sighted.
I was skeptical at first also, but once I made the leap (self-inflicted), I almost immediately noticed a vast productivity increase. One of the reasons we ditched tables was the reduced investment in maintenance time. The same principle applies here. Markup that might have been 200 lines of nicely formatted HTML might now be only 100 lines of nicely formatted HAML. This might not mean anything to you, but it might save the next person who has to edit your code a little time. And, in our industry, I think we can all agree a little time, is a LOT of time.
Secondly, with HAML, I have to type less, which means once I got quick with HAML, I got exponentially quicker with HTML (as output).
If you don’t like HAML, don’t use it. But if you want to tear it down, you should come with something better than this, because this is weak.
December 23rd | #
Todd: I am certain that any productivity increase is a perceived productivity increase. Writing actual HTML is not labor intensive, and if it feels like it — it’s a reason to learn the language and/or your text editor better. When you factor in the mental time required to create semantic tree structures and CSS, the actual writing should be a sliver of the time required.
And, don’t misunderstand my dislike for unfamiliarity, I’ve tried and used HAML in the past on a couple of different projects. I went from skeptical, to annoyed, to angry as the days went on.
How’s this for a better reason: HTML is a loosely coupled language. It is platform agnostic and framework independent. Anyone who calls his/herself a designer has a familiarity with it. It is the most prominent language used on the web and will be for years to come. It does not require a runtime nor a compiler, and can be rendered on nearly any modern computer on the planet without additional software.
I’ll happily keep my extra 100 lines.
December 23rd | #
Kyle: I think you are missing the point of HAML and Todd. Todd doesn’t write HTML that “any middle schooler” could do. HAML would be pointless for that. Todd and others like him write presentation logic that is dynamically generated and greatly distributed and repurposed. To have to go behind one of these developers and figure out what is going to be output involves turning off all the music, putting a do not disturb sign on the door, jotting down notes on index cards, and opening a gazillion includes, partials, and helper files. If (big if) you know HAML, it is much easier to maintain an app that you didn’t write when HAML was used in place of HTML. Most importantly it lessens the chances that you will introduce bugs in iteration/maintenance cycles.
Yes HTML is simple. It is too simple sometimes. Learning Ruby on Rails with all of its conventions and automagical code seems like a waste of time for the person who has always wrote their apps from scratch in PHP. I’ve often heard, “In the time it takes to learn the Rails way to do it I could code it in PHP.” But anyone who has had to inherit a massive in-house developed PHP app understands why Rails has gained favor.
If you think that liking HAML means that needs to learn HTML or TextMate/VIM (I’ll go ahead and fill in the editor for you) better, I might suggest that you haven’t had to maintain large enough apps to need HAML. However, I wouldn’t want to insult you having not taken the time to research your background.
While “agree to disagree” and “not forced to use HAML” sounds great. If someone has the foresight to see that a project will be complex enough to demand HAML, you shouldn’t have people taking it upon themselves to start checking in HTML to the repo. (Any more than they should change the space/tab convention, or replace CSS with tables.)
December 24th | #
Why does using a HAML template mean you won’t be using lots of partials and helpers. In my experience, it’s the opposite, since HAML has a simplified view of ruby and sort of forces you to add more helpers. This isn’t a bad thing in my mind though, it makes for cleaner, more encapsulated code IMO.
December 24th | #
I don’t believe this to be true. HTML is written very differently from person to person. Do you indent everything? Do you indent nothing? Some medium? How do you format nested tags? Do you use the same rules for inline tags and block tags? What about the html tag? Should you treat it differently?
Different people write HTML very differently because HTML allows a large margin of error.
My favorite feature of HAML is that there is one, and only one, obvious way to do indention. Since nesting is based on indentation, someone really can look at my views and understand them because I did it the same way, the only way. Its very pythonic in that sense. There’s nothing to argue about because there’s only one way.
The bottom line is that HAML is an abstraction and dismissing it as “clever” is stepping on some major tenets of programming in my opinion.
December 24th | #
One principle of HAML is the same as one of the Rails principles – the less code you have to type, the less chance for introducing errors/bugs. With HAML there are just less characters on the screen. I know HTML really well also, using it since 1999 myself. I’m just getting started with HAML. But it is clear to me when comparing the HTML and HAML versions of any moderately complex layout that the HAML version is more easily and quickly understood and managed, by a wide margin. I don’t force my designer to use it, but I convert his work to HAML when build an application. I’ve showed it to him and he’s intrigued, and if he starts using it we’ll be that much more productive together.
December 24th | #
HAML allows you to write markup at the same abstraction layer that you should be thinking about it in the first place, namely its semantic structure. In doing so, it uses syntax that is strikingly similar to CSS — so much so that you don’t have to have an ongoing mental mapping process to convert back and forth.
All the other benefits (readability, less typing, indentation, etc.) are just icing on the cake.
December 24th | #
You’re right that almost nobody uses it, even though it’s been ported to several languages and frameworks, has a TextMate bundle, and is an official Debian package. Oh wait – I think that makes you wrong.
Our experience, as a small studio with ninja CSS and front-end guys as well as Ruby heavyweights like Hampton and pre-37signals Jeff Hardy in the same room, is that designers love Haml. If you’ve been using HTML for a decade, Haml should take about a day to become proficient at. Meanwhile, eRB looks like a total shit-storm. Inline Ruby makes HTML look busy and by definition, it is not what you see when it is rendered. So, why the loyalty?
Reasons I love Haml are not limited to: auto-closing tags, beautiful indented output, a 1:1 relationship with my CSS, and allowing myself to visualize my DOM-to-be in my editor. It generates valid XHTML by default.
Haml has supported in-line blocks since early on, so any argument about needing to use more helpers is pretty much moot. I use few to no helpers. Everything in Haml is a self-closing block, which has the side-effect of making many errors easy to spot.
I think the truth is that we don’t need/want you to use Haml. It makes us better/faster, and that gives us a competitive advantage. Ignore at your own peril.
For the record, I was the guy that told Hampton not to write Haml (it sounded like a terrible idea) and now I wouldn’t dream of doing a project without it. I hope being user #1 gives me a qualified perspective.
December 24th | #
HTML is great by itself. ERB is simply not HTML. Mixed with code a clean document structure often ends up with some ugly strings of junk text that can be annoying (and slow) to parse visually.
“>@objects.method2
the
%>”>
sprinkled liberally in your document draws attention away from where it should be: the structure of your document.
We’ve yet to run into a designer who is confused by swapping less than/greater than for percent sign and indentation. It’s not like haml has replaced well know tags for some brand new terminology.
I’d say it’s less like learning Chinese to travel to Spain and more like reading a Spanish sign written in a different font. “I couldn’t possible understand what that sign says. After all, my spanish text was all written in Geneva Regular. I find Spanish barely understandable when written in Times.”
December 24th | #
So how about that Sass markup? Man I love that shit… ;)
December 24th | #
Nice article Short-sighted and clearly poorly researched. You are, of course entitled to your opinion; the reason I am saying this is because if you had spent [literally] 10 minutes to look at HAML in any sort of objective fashion you’d already see it’s advantages. In fact, you’d already have learned it. That is litterally how long it took me to learn the syntax, and it’s already made my coding life more enjoyable. Anything with such a slight learning curve that can do that is worth it’s salt.
December 24th | #
Ruby outputs binary, it’s totally stupid to write in Ruby to begin with!
December 25th | #
Always fun to see people who read my titles, not the body and comment :)
brad dunbar: I think you’re one of the first ones to make any kind of a coherent argument, thank you. Stylistic differences in HTML is a problem, no doubt and that’s the only thing I can say I really like about HAML: it’s a forced styleguide.
Obie: Maybe it’s just my experience, but I find people the write HAML end up with less semantic code. I find that they don’t have to think about their tags, and just end up with divs upon divs upon divs instead of considering the semantic nature of the data and selecting the tags as appropriate. And, it might just be how I code — but I found myself constantly getting lost in HAML code. I never know what level something is in. The lack of being able to put in end-markers (
<!-- /.classname -->) like I do in my HTML gets me feeling like I’m staring at a 5-way intersection without any signs.Yardboy: I’d disagree Rails is about less code. If anything, Rails favors clarity over character savings. (
number_to_human_sizecomes to mind)Dag: No idea what planet you’re living in. Pretty sure my Ruby is run through an interpreter.
December 25th | #
Actually, Haml supports putting HTML comments in your document:
December 25th | #
Forgive the awkward spacing in the code snippet above: I’m used to Textile as opposed to Markdown.
It should look like so:
Which outputs this:
December 25th | #
Will: I think you misunderstood… here’s what I mean by ending markers:
XML solves this by allowing custom tags (peanutbutterjelly), unfortunately HTML is not so lucky.
December 25th | #
I don’t see anything special beyond having the final comment on the same line as the closing div tag. If that’s all, I don’t see what all the fuss is about. The location of a comment doesn’t make it any easier or harder to find with incremental search when it comes to the difference between immediately after another tag or a line of its own.
If you’re referring to something else, I missed it.
December 25th | #
Will: Personally, I think it makes a huge difference. It’s hard to show without lots and lots of lines of code, but I find having a text note is much easier to see than the difference between 4 & 6 spaces of indentation.
December 25th | #
Well, different strokes for different folks I suppose.
December 26th | #
So, how about Builder? When you need to output XML — like for an Atom feed, say — do you write it all out by hand, or do you use Builder?
What about migrations or ActiveRecord? Do you use the fancy finder conditions, or do you always use findbysql?
December 27th | #
@kyle=
Not to pick on you too much (if you don’t like HAML, that’s fine with me) but I think you really missed the point of Dag’s comment earlier.
“Ruby outputs binary, it’s totally stupid to write in Ruby to begin with!”
A little hint of sarcasm here goes a long way. HAML makes HTML much more enjoyable for many coders, just as Ruby makes programming more enjoyable, but you could just sit down and write binary…
December 27th | #
Christian: No, I totally got it. I choose not to debate people who take a rational argument (something you posted) and whittle it down into hyperbole. I just found it funny that he got his hyperbole wrong :)
December 28th | #
@kyle=
Ok, my apologies.
Back to another point you made earlier… You said that you don’t like the fact that you can’t have the closing comments at the ends of your closed HTML elements. Do you really find yourself debugging in vanilla HTML source code all that often? I don’t think I’ve debugged in plain-old source code since I discovered Firebug. With Firebug’s auto indentation and collapsible, nested hierarchy, debugging HTML is incredibly simple. In fact I find it odd when I find designers/developers who don’t use Firebug.
One point I’d like to make – and again this falls under the category of “to each their own” – is that HAML basically forces you to write beautiful markup. I was (and will forever be) a stickler for clean and indented markup, but the fact that you must indent properly in order for HAML to work puts everything in a simple and logical order which makes is ultra-readable. Now, this is not nearly as beneficial for me when I’m working on my own as it is when I’m working with other developers. Now my co-developers and I all have the same guidelines to follow, and all of our HAML looks basically identical. This is a huge plus for me and for the general readability of our code.
January 2nd | #
I think HAML as more of a tool than a language. In the same way that you use text editors to help you write code (be it with snippets, highlight etc.) you can use HAML to help you write HTML. When using a text editor, you still need to know the language you are writing, but it can assist you greatly. Same with HAML.
January 4th | #
Christian: I actually do debug vanilla source a lot. Perhaps because I do a lot of work with Javascript and Firebug shows the real-time HTML, not necessarily what the server is giving me.
Sam: I think of HAML more like shorthand used by court reporters. It may be easier and faster to write, but comes at a cost of legibility. Court reporters can read it no problem, but anyone off the street? Not so likely. It may help the author greatly, but can also hurt newcomers much more than the initial help.
January 5th | #
@kyle,
to your last point: maybe it’s not for newcomers. i’ve been writing html since about 1996 and i wouldn’t tell anyone to start with haml. but as the front end lead in a small shop i’ve been incredibly excited and pleased with haml. it enforces consistent markup, as has been pointed out. it’s a lot fewer lines, and it just makes sense. i think it goes with ruby/rails so much better than plain vanilla xhtml. for me, it’s like chocolate and peanut butter. erb templates become ugly messes rather quickly, and since we build and maintain multiple large rails apps, it is looking like a real time saver.
the ultimate testament, though, is that once i started using it i was happy. it put a smile on my face, and the first thing i did was put together a presentation for my co-workers to give them the basics and get them fired up. how often does that happen? we’ve all found it incredibly easy to grasp, very straightforward to convert old erb templates to, and fun to write.
now i wish i could use it everywhere, because i would so much rather maintain my wife’s blog templates in haml than html mixed with php. ugh.
so, to each his own. if you’re not into it, fine, but trying to argue that it’s bad is a whole different thing than saying it’s not your cup of tea.
January 5th | #
[...] Neath has a post claiming that HAML is completely unnecessary. My main beef with HAML is that it’s completely [...]
February 27th | #
I just love how people make definitive judgement calls about software they have never used enough to truly grasp.
My .haml templates are typically between 50 and 60% smaller than their .rhtml predecessors.
That means I’m doing half the work, but still making the same money. Do the math!
I also love how you dont make any mention of Sass, which runs circles around CSS. You can use partials, global constants, conditional logic and mixins to really make your stylesheets DRY – you even have compression options to minify your css files for production.
As for difficulty, I learned to master haml in the time it took you to sit here and slag it with this half-assed piece of writing – I’m willing to bet your html is as sloppy, invalid and useless.
But hey man – whatever floats your boat.. I guess some people love writing the same methods, classes and attributes OVER AND OVER and jamming nasty interpolators, PHP style into their templates.
It’s pretty obvious to me which toolset is more productive and elegant.
February 27th | #
Alan: I assume you didn’t read my post or subsequent comments where people claimed the same thing (one of my favorites). I’ve used (and continue to use on and off) HAML quite a bit.
February 27th | #
And on that note I’m closing comments — I think we’re down to the trolls now unfortunately.