Comments for The Opinionated Programmer

Comment on haml, an objective view by Darin Burris

Darin Burris — Tue, 04 Aug 2009 20:29:02 +0000

People that argue that HAML is cleaner and easier to read, thus saving hours of effort in “chasing down curly braces” must be used to sloppy markup.

As a visual designer as well as a front-end developer, I strive to write beautiful, elegant, simple, and very clean markup. I don’t see why this isn’t enough.

I also don’t understand the desire, and apparent need by some developers, to abstract something as simple as (x)html to begin with. I can understand abstracting a complex programming language, but (x)html isn’t a programming language and isn’t complex.

Comment on haml, an objective view by Brian Hogan

Brian Hogan — Thu, 11 Jun 2009 00:24:48 +0000

Haml is extremely valuable to speedy implementations of sites because you don’t get to launch your site with invalid markup, which means you won’t fight as much with CSS or JavaScript DOM parsing. That alone is worth the price, and it’s one of the chief reasons it’s become so popular.

If you’re concerned about performance, you need to look at other factors besides view rendering. On any site where view rendering performance is a concern, you simply implement caching, either fragment or action caching, or even static page caching, which is a good strategy to employ anyway.

Whitespace programming languages have existed for a long time, and they continue to do so because of the fact that you simply cannot get past the compilation stage if you don’t structure your code properly. Chasing down curly braces or if…ends in long files (or closing tags) is a lot of wasted time. Considering you read code ten times more than you write it, readability is vital to your success.

One more point: HAML is useful outside of Rails. You can use it to generate static web sites too using the StaticMatic gem. This removes the rendering cost. It’s also a great fit for Sinatra.

Comment on haml, an objective view by crabtrgr

crabtrgr — Mon, 01 Jun 2009 18:07:22 +0000

I understand your points, this is more of a subjective look at it. I do want to mention that even though you disagree with my arguments, I am assuming this means that you don’t disagree with my conclusion as you didn’t mention it.

As stated, yes, I personally have a few issues with it, but there was only one real point that I could find about haml objectively, and that was the performance issue.

As for your question about performance, here is a link

Comment on haml, an objective view by Kevin W. Gisi

Kevin W. Gisi — Sat, 30 May 2009 06:15:26 +0000

I don’t think you really make much of an argument here. Your first point references the fact that it breaks a convention that you’re familiar with — which is fine as an argument against personal use. However, with new technology, that will only be avoided in situations where something is 100% backward-compatible. If you wanted to make an argument that ERB is a better tool because it is entirely backward compatible with static html pages, I will fully agree!

As to the second point, it’s not fair to use unfamiliarity as an argument against use. Some users may choose not to run Linux because of the lesser documentation and “hold your hand” tech support. However, this is not a reflection on the Linux operating system, but rather a reflection on the capabilities of the user, and what technology best suits them.

All in all, this is a subjective look at Haml, not an objective one. You lay out two good reasons why you — or another developer with a similar background — might decide not to use Haml, but only one comment regarding its objective peformance — the double-rendering.

Can you site the statistics on Haml’s performance, because I was under the impression that it performed on par with ERB.