47

I have been playing with Haml recently and really like the way the resulting code looks to me...the developer. I'm also not too worried about a designer being able to consume or change it...we're a small team.

That said, beginning work on a project we believe will generate quite a bit of traffic (who doesn't?). I'm concerned that there are things I just don't know about haml. Is there anything erb can do that haml can't? Does haml have a negative effect as a project grows? Are there other things that should be considered?

And finally...how does Haml compare speedwise to erubis? I see that it supposedly beats erb and eruby now...

Thanks!

James A. Rosen
  • 64,193
  • 61
  • 179
  • 261
  • Personally, I'd worry about scalability when it becomes an issue. After all, the database takes most the time when compared against view rendering. (At least so far as I've seen.) – Robert K Dec 22 '08 at 21:51
  • 3
    On the flipside, if you only worry about when it becomes an issue, what do you do if you decide that your templating language is too slow and you're stuck with tons of views written in that language? – outcassed Aug 02 '09 at 15:45
  • Good point Casey - the templates are the hardest part of a web app to convert. – thethinman Mar 01 '10 at 23:30

7 Answers7

45

Haml rocks. I haven't seen any recent performance numbers but it is pretty close to erb these days. I think that it might be faster than erb if you turn on ugly mode (which prevents the pretty indentation) We're doing 2.8 million pageviews a day with Haml.

There is a benchmarker checked into the Haml source tree: http://github.com/nex3/haml/tree/master/test

Update November 2009

Nathan (Haml's main developer) published some Haml 2.2 benchmarks on his blog. You can see the exact numbers there but in short:

  • Normal (pretty printing) mode = 2.8 times slower than ERB
  • Ugly mode (no pretty tabs added) = equal to ERB

You can enable ugly mode by placing Haml::Template::options[:ugly] = true in an initializer or environment file. Note that ugly mode isn't really that ugly - the resulting HTML is actually much prettier than ERB - it's just not indented nicely.

outcassed
  • 5,223
  • 2
  • 27
  • 24
  • 1
    your number and provided benchmarks are quite impressive. And it's nice to know about ugly mode :) – Dzung Nguyen Nov 24 '10 at 16:48
  • 11
    It's not necessary to set `ugly` mode for production in initializer because HAML enable this mode in production by default. – Voldy Nov 29 '10 at 13:17
27

If you use Rails, the performance difference between Haml and erubis is negligible: templates get compiled and cached after the first hit, anyway. Combine this with fragment and page caching and you can rest assured that views are not the performance bottleneck of your application.

The question you should be asking yourself is: do you like writing Haml? Does it make you more productive? Then you can decide easier.

mislav
  • 14,919
  • 8
  • 47
  • 63
11

I love HAML since it is a good tool for easily writing structured HTML, and generally it is just a joy to use. But it has very little to do with choosing a tool based on the amount of traffic a site might have.

If you are worried about traffic, you should worry about using caching properly. And then you need to apply the principles of general web-application performance - the result is that you will have super snappy responses to page loads. Which is what a high-traffic website really needs.

A couple of presentations that show how to improve website performance can be found here:

And the best place that I know of to learn how to use rails caching properly is:

Evgeny
  • 6,533
  • 5
  • 58
  • 64
4

I think it's entirely a matter of personal preference and maintainability. For me, Haml makes the templates easier to read and understand, and the performance is very acceptable. In the end, the templating language is unlikely to be the place where you need to optimize -- more likely database queries, view or object caching, etc.

However, in the case of ERb templates, you will get better performance essentially for free if you use erubis.

seancribbs
  • 1,495
  • 10
  • 6
2

If you like how haml works from a coding point of view, don't worry about the performance of the templating engine too much. (Though, as you've pointed out, it's now fast.) It can definitely generate any output the other engines can.

Generally, it's more profitable to put your energy into setting up caching than worrying about your templating engine where you're having performance problems.

Nate
  • 4,561
  • 2
  • 34
  • 44
1

I would personally recommend us erubis in precompiled templates.

Especially if there's no need for dynamic templating. Then your biggest slowdown will be limited by the speed at which ruby can parse ruby.

I'd probably set up a small cron job that just monitors for changed source templates and autocompiles them on-change that you can turn off when not in use.

Compile once, use many.

Oh, and if you're really concerned about speed, Tenjin may be worth a look too ( same creators as erubis )

http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html

Kent Fredric
  • 56,416
  • 14
  • 107
  • 150
0

Well, Haml performance continues to improve with each release. Is it at an acceptable place at the current time? That's for you to decide (I'm inclined to say "Yes", but it's your choice based on your needs). If you like the templates and the readability they provide, then the performance drop (however negligible) should really be the final factor in your decision.

One of the other tools you should consider using in conjunction with Haml is make_resourceful, another gem by the maintainer of Haml (Nathan Weizenbaum) that simplifies a lot of the RESTful things in a Rails app.

If you have any further, more specific questions about Haml (and m_r), I'm sure Nathan would be more than happy to answer them. He can be reached via Jabber/XMPP and email. His contact information can be found here.

wfarr
  • 1,563
  • 1
  • 13
  • 13