HAML: RoR's new templating engine

Rails
41

I have been following this thread, though not too closely so I may have missed
some of the following points.

I’m happy to clarify them.

  1. My first impression is HAML is so “leading edge” that current editors don’t
    have any support for it yet.

yes, wysiwyg editors have absolutely zero support. However, every
designer I know has dropped wysiwyg for a powerful toolkit of
in-browser css editors and etc.

I’d welcome someone to write that, but its not something any of the
designers I know using this require (or have asked for).

  1. Although RHTML isn’t “special” or “better” than ASP, JSP and the likes. However,
    besides good compatibility, vanilla HTML do not need further processing. In HAML
    just about every line needs to be transformed (HAML -> HTML or whatever). This
    beg the question of performance. Are there performance issues we should be concerned
    about?

It is slower. And you are right that it will always be a bit slower.
However, DBs remain the bottleneck in producing a page, not rendering.
While RHTML may be 2% of the render-time for a certain page, HAML is
about 3-4% of the time. That’s absolutely acceptable in my mind when
DBs take up 85% and are still the actual slowdowns.

Caching isn’t implemented yet, but it will be soon. (Patches welcome!)

  1. HAML perhaps may be easily learned but I wonder how well this works in practice.
    It is another layer of abstraction web designers/authors will need to deal with. I am not
    sure how well HAML will be accepted in their world.

Every designer that I know that has used it “in the real world” won’t
work without it now. They refuse to use anything else. Not
coder-designers, just designers.

HAML makes it much easier for a designer to parse in their mind what
is going on because of the syntax and etc. If statements, loops,
blocks, and hand-coded XHTML is probably the worst thing for a
designer to have to deal with. They should only care about
understanding the structure in the DOM.

We at unspace interactive have been using this successfully in all of
our projects over the past 3 months. It wasn’t introduced after it was
created. We held it back to give it its paces and to see how it worked
out. There is a reason that we flew across the world to introduce it
at RailsConf Europe. Its because it works in a real-life situation and
produces great code with very little overhead.

Our goal is to deliver value to our clients, and HAML helps us
accomplish that.

It works. Period.

-hampton.

PS: Though, we are always improving!!! It isn’t finished yet. But,
now is the world’s chance to make improvements and to make it kick
even more ass than we could do internally.

42

Speaking to the implementation issues of using loops, I’ve submitted a
patch that allows the following:

  • for page in @pages
    %h1= page.name
    .page
    = page.text
  • end
    This works for all types of blocks. It should be possible to eliminate
    the need to manually type “end” as well. So it’s not a problem to
    implement loops and blocks in HAML… it’s just an issue of whether or
    not we want them.

Personally, I feel that loops and especially if statements are
neccessary for the language. There are certainly many times when
they’re inappropriate, but there are also many times when they’re
legitimately useful. In addition, they’re an integral part of Ruby;
various methods built into the language and into Rails rely upon
blocks, the ability to key off a boolean, and the like. HAML won’t be
able to use any of this if it doesn’t support blocks.

43

I’m going to have to agree on the designer issue. If your designer is
using
DreamWeaver or some other WYSIWYG program, they won’t like HAML. At
least at
first. HAML is more like the underlying document structure. Not every
design
requires knowledge of the document structure, but most good designs are
deliberate and are mindful of the document structure. If you design is
not
in this category, rhtml still works fine.

One thing that would really help me (and I believe others) understand
the
“it works” part of this equation is a non-trivial example of one action
that
really does something interesting. Something that really exercises HAML
so
we can learn by example.

This might include a form so we can understand why form_for blocks are
not
as interesting in the context of HAML. Additionally, please consider
Ezra’s
comments about joining block statements because I know there are many
instances where I do things like:

<% content_for :sidebar %>
some arbitrary stuff, optionally drawn from instance variables
<% end %>

or even more frequently:

<% content_for :title %>

Thanks for opening this up to the rest of the Rails world.

Hampton wrote:

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6342894
Sent from the RubyOnRails Users forum at Nabble.com.

44

And the patch is … where?

Nex3 wrote:

the need to manually type “end” as well. So it’s not a problem to

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6343610
Sent from the RubyOnRails Users forum at Nabble.com.

45

Hampton wrote:

I’m going to make
it clear that I think 99% of the loops in views are crap and are
against HAML style.

Odd, since many others here disagree, and so many other existing
template languages do as well…

Joe

46

@s.ross: Here:
http://dev.hamptoncatlin.com/haml/ticket/16

47

I feel like the suggestions for how to handle multi-line blocks here
are turning HAML into an ugly beast, should they come to fruition. It
seems to me that there are probably ways to figure out when a
multi-line statement terminates without any explicit help. For
starters, if = is encountered, but no special symbols for subsequent
lines, couldn’t you assume the expression continues until the next
special symbol is encountered?

For what it’s worth, I can tell you right now that I’d pretty much drop
HAML like a hot potato if it turned into something that required me to
do == or | for every line of a block. That seems very far off the mark
for what HAML promised out of the gates.

48

Don’t worry, my patch deals with this. All you have to do for a block
is:

  • block_magic do |param|
    = param.stuff
    %p= param.magic

No closing tag or repetitive characters needed.

49

I would add that one of the most Rails-esque things to do is just get
something working and then polish it up later. TDD encourages this too.
Here’s an example from scaffold:

<% for column in Catalog.content_columns %>

<%= column.human_name %>: <%=h @catalog.send(column.name) %>

<% end %>

<%= link_to ‘Edit’, :action => ‘edit’, :id => @catalog %> |
<%= link_to ‘Back’, :action => ‘list’ %>

Without knowing anything about the underlying model, this view uses
loops to
iterate over the members of the content_columns collection twice. Yeah,
the
problem can be solved other ways. It probably will be solved a
different
way in the final implementation. But somethings just getting the CRUD to
work is enough to see whether you’re headed in the right direction.

Would this be sooooo evil to include in HAML?

–steve

Joe R. MUDCRAP-CE wrote:

Joe

–
Posted via http://www.ruby-forum.com/.

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6344104
Sent from the RubyOnRails Users forum at Nabble.com.

50

I am developing a Rails site and am gearing for deployment. The one last
bit I want to do (and need help with) is to make the site more
professional
looking.

  1. I need a good stylesheet color scheme for font, div borders and
    background.

  2. I am somewhat a minimalist. I only need a handful of graphic icons
    and
    maybe a site logo.

  3. The overall site layout is done and set. I may need help with layout
    for
    specific areas within a page.

Work will be off-site. I don’t think it will require a lot of work (I
could be
wrong) but if you are interested in helping, send me a note to

long755[@]rogers[dot]com.

In the message, describe your background and current work. Please
include
links to live sites that you’ve designed or created graphics for. Note,
resumes
will NOT be read.

I want to thank you all for your interest, but only successful
candidates will
be contacted for round 2.

Cheers,

Long
PS: If you know of a good designer please forward this message.

51

Checking back in… I lost steam with HAML. Going back to the few
templates I initially converted, I’m not sure I like it as much. I do
want to keep an eye on it, though.

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I’ve heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

This is just what I’ve heard, and I’d be interested for more of your
take on this.

52

Seth Thomas R. wrote:

This is just what I’ve heard, and I’d be interested for more of your
take on this.

My bad. I somehow created a new thread that followed this one…

Back to rendering performance. In a templating system, my understanding
is that static content is usually pushed to the template and one tries
to keep
dynamic content to a minimum. Rails has many helpers that are used to
transform
to static html, for convenience. This can be good but the cost is
performance when
it is over-used. With rhtml developers do have more control and can
balance/tune
rendering speed more easily. I don’t think the same can be said for
HAML.

Long

53

I applied this patch and as I noted in Trac, it causes certain breakage
in my
code. Maybe I did something wrong…

(eval):3:in `template_eval’: compile error
(eval):3: parse error, unexpected ‘(’, expecting $
$HAML_instance << “”( “fine” * 3).to_s << “\n”
^
Extracted source (around line #0):

1: = “fine” * 3

Here’s the template that breaks (expected result: finefinefine):

= “fine” * 3

And one that works around the above error:

%p= “fine” * 3

Nex3 wrote:

–
View this message in context:
http://www.nabble.com/HAML%3A-RoR's-new-templating-engine-tf2268612.html#a6346496
Sent from the RubyOnRails Users forum at Nabble.com.

54

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I’ve heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

On my production site (which is currently in closed beta) DB is
consistantly less than %20, and often under %10. I’d have to agree that
rendering is the main bottleneck.

Just a thought…maybe the DB is the bottleneck on all ur sites because
ur using HAML without caching support (which at view level, requires
blocks)…it’s possible.

Anyways, I, like most others in this discussion, think HAML has a LOT of
potential and will be a great product once it matures a bit more and
supports caching and blocks with a nice, easy syntax. Until then I won’t
be using it, but I will be watching it’s development closely. Keep up
the good work :wink:

Golly

55

Seth Thomas R. wrote:

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I’ve heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

I’ve never had performance problems with rendering. DB is the only one
I’ve had to watch for.

Joe

56

[Oops, repost cos I replied to the wrong email…sorry]

Hampton, you commented on DBs being the bottleneck, not rendering, but
from what I’ve heard (including from members of Rails core), rendering
has actually been one of the most notorious performance monkeys on our
collective back for most of Rails life thus far.

On my production site (which is currently in closed beta) DB is
consistantly less than %20, and often under %10. I’d have to agree that
rendering is the main bottleneck.

Just a thought…maybe the DB is the bottleneck on all ur sites because
ur using HAML without caching support (which at view level, requires
blocks)…it’s possible.

Anyways, I, like most others in this discussion, think HAML has a LOT of
potential and will be a great product once it matures a bit more and
supports caching and blocks with a nice, easy syntax. Until then I won’t
be using it, but I will be watching it’s development closely. Keep up
the good work :wink:

Golly

57

I’ve noticed consistent problems with rendering times. DB queries (once
memcached) doesn’t seem to be an issue. Especially the link helpers and
the
routes are pretty pathetic when it comes to speed (and even nominally
complex routes). I haven’t played around with Edge (or REST) but in the
last
rails stable, rendering is a bottleneck. Stafan Kaes has a template
optimizer (and some pointers to route generation) which has helped me a
lot.

Vish

58

When you guys say “DB is consistantly less than %20”, where do you get
that
from?

59

blinking bear wrote:

When you guys say “DB is consistantly less than %20”, where do you get
that
from?

If you look in the log files you can get info on rendering/DB time.
Eg:
Completed in 0.07800 (12 reqs/sec) | Rendering: 0.04700 (60%) | DB:
0.01500 (19%) | 200 OK

60

I am certain that for your site that must be true. However, that does
also lead me to believe that you aren’t doing DB calls that are that
intensive. Doing three joins across tables that you can’t really cache,
because its over several servers and is constantly changing. I
generally have DB calls that are about 70% on most of the major calls
to server.

As far as speed in HAML goes, there are a couple notes about it. We
have achieved a 20-30% speedup already in the latest version (0.2)

With silent-scripting, I think that rails-caching probably works now,
though I haven’t tried it out yet.

And, beyond that, we are currently starting work on building a C
compiler for HAML (and its derivatives also in development). Basically,
in version 0.2, HAML does some compiling before it gets executed. Very
similar to what ERb does. Anyhow, we noticed that we would very likely
be able to move this code into a C library and have it spit out HAML
buffered-ready code very quickly. Adding that into the codebase (might
show up around 0.5) should make us faster than ERb.

Though, only time will tell.

Anyhow, I appreciate the feedback on HAML and will take your concerns
on speed to heart and work even more on getting speed-ups. However,
though I am working to improvements, I don’t think that speed should
keep anyone from actually using it in production. Yes, it is slower,
but its not so slow that your site would come to a crawl in any real
sense.

All of our sites still feel zippy.

-hampton.

On Oct 1, 9:26 pm, David B. [email protected]