Performance of Markaby, XmlMarkup, Haml Haiku and Malline?

[josh]

Hi all

I just stumbled over some template engines that claim to make live
writing clean HTML easier.
I am a quite experienced HTML programmer, who has no problems creating
clean, maintainable, valid XHTML code. So I wondered what great benefits
I would have from using such template engines except the computing
overhead they produce.

Is there any big advantage why one should switch to using one of them?
Or are the benefits too small regarding the computing overhead?

Thanks for your opinions,
Josh

[josh]

I use HAML. I also have no trouble creating valid XHTML but then I tried
HAML. Unfortunately, it is hard to explain why it is awesome. First, it
removes the unnecessary cruft from html. It brings html into a much more
DRY form. So

this is an example

becomes

#example-1.example
%p.hello
this is an example

it may not seem so amazing now but comparing full html documents with
haml, the haml is more concise, easier to change, and it is much easier
to see quickly the general flow and hierarchy of the document.

I have done benchmarking on the HAML vs ERB and frankly the rendering
speed of HAML is never the bottleneck in an application and the
rendering difference is barely noticeable in a real-world environment
with proper caching, etc.

There are more benefits but I will stop there. You should really just
try an alternative templating language on a single project. If it
doesn’t fit your taste, you can always go back to the default at any
time.

[josh]

Haml is only 5-12% slower than ERB when ran through ActionView according
to
it’s release notes.

It saves a crap load of time too by not having to repeat yourself (such
as
putting end tags for everything) It also makes it all much nicer when
your
code is indented exactly how it should be instead of all resting on the
left
margin. It’s such a beautiful language, and Nathan gave an
almost-perfect
example of its use.

#example-1.example should be just [example], as this will create a div
with
the id of example_#{example.id} and a class of example.

[josh]

Heh, thanks Ryan. I wasn’t even aware of that little gem with the square
brackets. You prompted me to go read the full haml reference again.

[josh]

Ryan B. wrote:

Haml is only 5-12% slower than ERB when ran through ActionView according
to
it’s release notes.

It saves a crap load of time too by not having to repeat yourself (such
as
putting end tags for everything) It also makes it all much nicer when
your
code is indented exactly how it should be instead of all resting on the
left
margin. It’s such a beautiful language, and Nathan gave an
almost-perfect
example of its use.

#example-1.example should be just [example], as this will create a div
with
the id of example_#{example.id} and a class of example.

Okeydokey, it sounds interesting. So although I’m quite proud of my
precise XHTML skills I’ll take a look at HAML.

[josh]

I use HAML. I also have no trouble creating valid XHTML but then I tried
HAML. Unfortunately, it is hard to explain why it is awesome. First, it
removes the unnecessary cruft from html. It brings html into a much more
DRY form. So

I tried HAML and got really frustrated by it.

It’s very finicky. It mandates two spaces for indentation and makes no
allowances for people who might prefer more space.
It doesn’t work with tabs at all.
I could not find a way to put inline styles or inline javascript
(maybe it’s possible but it was not in the docs).
It makes it very difficult to move sections of markup around. If you
want to move a table from one div to the next you have to practically
re-indent your entire page.
If you make an error (and you will) the error message does not tell
you on which line you messed up. You have to examine the entire page
top to bottom to see where you messed up.

I think if haml had a “flow” option like YAML does it would be ideal.
I guess at that point it would be like markaby too.

Too bad markaby is no longer being maintained.

[josh]

Hi and thanks,

this thread encouraged me to take a look at haml. With a busy
schedule it is always a balance as to whether to carry on designing
and writing code or stop and look at ways to be more efficient. So I
stopped and looked and yes - very nice.

Not only does haml simplify the view enormously (and the future amount
of typing), but it has an impact on helpers too.

I had a table row that used a helper to generate a complex string to
insert into the tr tag to provide the following:

-mousein and mouseout styles
-an onclick url based on the row item
-odd/even styling.

When I converted to haml, I was stuck for a few minutes on this, but
the documentation is very good. And so after a few minutes I had
removed a substantial amount of clutter from the helper and converted
my string construct to a hash called like this from the haml view:

%tr{onclick_list_haml(product_row, ‘edit’, cycle(“odd”, “even”))}

The helper itself is now much, much easier to read and maintain. I
expect a real gain in future coding.

The plugin is easy to add, and the views can just be copied into a new
file with a haml extension and then converted to haml (which
predominantly involves removing redundant dross and tidying up the
indentation). The haml file takes precedence over the rhtml file. So
it is easy to change the views one by one (leaving the original
intact) without breaking the application.

I also found the radrails plugin which helps with highlighting the
head of the indented block.

So I’m impressed; and it has brightened up my Monday morning.
Thank you to all the guys who have worked on the haml implementation
and also very much on the documentation too!

Tonypm

[josh]

I think if haml had a “flow” option like YAML does it would be ideal.

Could you explain this point further? I don’t know what the flow option
is.

In a yaml file you have the option of “flow” type of an entry or the
indented entry. For example a list in yaml is like this

• item1
• item 2
• item 3

or the flow method

[item1,
item2,
item3]

if you use the brackets you don’t care about the indenting

If Haml had that I would be all over it.

[josh]

I could not find a way to put inline styles or inline javascript
(maybe it’s possible but it was not in the docs).

Sure it is possible.

%bla{:style => “some-attribute:some-value;”} Bla

It makes it very difficult to move sections of markup around. If you
want to move a table from one div to the next you have to practically
re-indent your entire page.

I agree with that. It’s sorta cool to have to write only as much code as
is really needed, but it has some implications on basic workflow
(TextMate gets confused about what I want to do when moving blocks
around either).

If you make an error (and you will) the error message does not tell
you on which line you messed up. You have to examine the entire page
top to bottom to see where you messed up.

I also agree with that, however, after a few hours you won’t make any
mistakes anymore. It’s just a question of practice.

I think if haml had a “flow” option like YAML does it would be ideal.

Could you explain this point further? I don’t know what the flow option
is.

All in all I really like HAML, but it’s not perfect. I also wasn’t able
to figure out how to place inline-code:

%p
Greetings,
= link_to(user.name, user_path(user))
!

This lets the browser display a space between the link and the
exclamation mark:

Greetings, User !

Anyone knows how to avoid this?

Anyway, if you don’t like HAML - the other part of the package, SASS, is
really amazing in my opinion! CSS quite the way it was meant to
be!

[josh]

After playing around with HAML for some weeks now, I have to admit that
I’m not convinced of it anymore. Well, it has cool features, and SASS
gives us a lot that I’m missing from CSS since years already.

But the longer I’m using it, the longer I get annoyed by the small
things already written in this thread before. And I don’t like looking
at the code, too, the idea behind using intendation for structure is
cool, but it also confuses me the longer I’m staring at it.

So I decided to try out Markaby, because it is rather a compromise
between “normal” XHTML and the cool advances of a “real” templating
language. If this doesn’t work out (which rather won’t be the case),
then I’ll go completely back using ERB only.

For SASS, it’s quite the same. If it had a more CSS-like syntax like

div {
color: red;

.box {
border: 1px solid green;
}
}

I’d rather like it, but I came to the conclusion that writing clean CSS
based upon a good understanding of the structures/elements of your
design is nearly as good, and it doesn’t bring all the hassles.

So I’m happy having played with different templating systems a little,
so now I’ll have a good feeling staying on the old ERB road and don’t
have the feeling I’m missing something I might regret soon.

One last thing: I read on several places that HAML was incredibly fast
compared to Markaby. Is that true?

[josh]

Do you mean something like:

%p= “Greetings “+(link_to(current_user.login,
user_path(current_user)))+”!”

which yields

Greetings arc!

Now do the same for

Greetings, User!

[josh]

Joshua M. wrote:

All in all I really like HAML, but it’s not perfect. I also wasn’t able
to figure out how to place inline-code:

%p
Greetings,
= link_to(user.name, user_path(user))
!

This lets the browser display a space between the link and the
exclamation mark:

Greetings, User !

Anyone knows how to avoid this?

Anyway, if you don’t like HAML - the other part of the package, SASS, is
really amazing in my opinion! CSS quite the way it was meant to
be!

Do you mean something like:

%p= “Greetings “+(link_to(current_user.login,
user_path(current_user)))+”!”

which yields

Greetings arc!

[josh]

Tim U. wrote:

I tried HAML and got really frustrated by it.

That’s too bad. I’m the main Haml developer, so I thought I’d try to
address some of the issues (even though this post is a month old… for
posterity, you know).

I could not find a way to put inline styles or inline javascript
(maybe it’s possible but it was not in the docs).

You want filters - see the section of
http://haml.hamptoncatlin.com/docs/rdoc/classes/Haml.html on filters.
The :plain filter will allow you to embed any sort of plain text in the
document, although you may prefer the :sass filter for CSS. For example:

%style{:type => “text/css”}
:sass
p
background-color: green

The same goes for Javascript. In the Haml master branch, there’s also a
:javascript filter that wraps its content in script and CDATA tags.

It makes it very difficult to move sections of markup around. If you
want to move a table from one div to the next you have to practically
re-indent your entire page.

I sympathize, but the same is true for normal XHTML. Unless you’re
willing to leave oddly-indented blocks of markup lying around your
document, it’s just as much of a pain (more, if you can’t end tags
). Also, a sufficiently smart text editor should be able to do this for
you.

If you make an error (and you will) the error message does not tell
you on which line you messed up. You have to examine the entire page
top to bottom to see where you messed up.

This is a bug in Haml that I’ve been working on fixing. I think
(crosses fingers) that it’s been squashed in the master branch.

Joshua M. wrote:

One last thing: I read on several places that HAML was incredibly fast
compared to Markaby. Is that true?

Yes. Since Markaby’s no longer maintained, there hasn’t been nearly as
much optimization work put into it as into Haml. In addition, since it’s
all Ruby code, there’s no good way to cache partially-compiled templates

• this is where both Haml and ERB get most of their speed. In addition,
  Markaby has to dynamically generate and append every bit of HTML, which
  slows it down tremendously even in comparison to uncached ERB (the same
  is true for Haml, but since it’s cached it doesn’t matter).

%p
Greetings,
= link_to(user.name, user_path(user))
!

Here’s how I’d do it:

%p== Greetings, #{link_to(user.name, user_path(user))}!

Greetings, User!

The thing is, Haml isn’t built for inline markup. Inline markup is a
very different beast than structural markup, and what works for
structure - namely, indentation - doesn’t always work for inline. So
there’s nothing wrong in dropping to a more inline-friendly syntax, like
XHTML:

%p== Greetings, #{user.name}!

Or even Textile:

:textile
%(class: some_class)#{user.name}%

Note the latter version will only work in the master branch, soon to be
released as Haml 2.0.

[josh]

Also, a sufficiently smart text editor should be able to do this for
you.

So TextMate isn’t sufficiently smart? Anyway, I don’t see any way how a
text editor should be able know where a tag should end, when there’s no
end tag…

Yes. Since Markaby’s no longer maintained, there hasn’t been nearly as
much optimization work put into it as into Haml.

OK, there we go, good-bye Markaby…

All in all, I guess I will completely switch back to ERB templates.
They’re not very beautiful, but HAML doesn’t seem much more beautiful to
me, and at least with ERB I should never have compatibility problems.

[josh]

That’s too bad. I’m the main Haml developer, so I thought I’d try to
address some of the issues (even though this post is a month old… for
posterity, you know).

Thanks. I appreciate it.

You want filters - see the section of
http://haml.hamptoncatlin.com/docs/rdoc/classes/Haml.html on filters.
The :plain filter will allow you to embed any sort of plain text in the
document, although you may prefer the :sass filter for CSS. For example:

I’ll look at them.

The thing is that my smart editors (eclipse, jedit, netbeans etc) know
how to automatically indent HTML and XML. If I move a div from one
section to another I just the magical key combination and voila!

If you make an error (and you will) the error message does not tell
you on which line you messed up. You have to examine the entire page
top to bottom to see where you messed up.

This is a bug in Haml that I’ve been working on fixing. I think
(crosses fingers) that it’s been squashed in the master branch.

Fantastic.

Note the latter version will only work in the master branch, soon to be
released as Haml 2.0.

How do you comment out a section of code? I tried to use the
commenting as described on the documents but if the commented section
“spoiled” the indentation it didn’t work.

Anyway here is a feature request.

I would appreciate some sort of an option to use blocks so I don’t
have to use indents. Whether it’s do end or {} I don’ t care. After
all if I liked significant indents I would be using python

[josh]

Joshua M. wrote:

OK, there we go, good-bye Markaby…

Malline is very similar to Markaby. I’ve been working with it the past
few days and have run into a couple of problems, but the developer is
very responsive. www.malline.org and there’s a Trac at dev.malline.org.

Peace,
Phillip

[josh]

Tim U. wrote:

Anyway here is a feature request.

I would appreciate some sort of an option to use blocks so I don’t
have to use indents. Whether it’s do end or {} I don’ t care. After
all if I liked significant indents I would be using python

I second that request. I looked at Haml briefly, but turned away from
it when I learned that it is indentation dependent. For whatever
reason, I have always liked 4 character tabs. I have tried a few times
to get away from that, but can’t. Not trying to start any kind of
debate, though. Just stating my personal preference. If Haml supported
blocks and let me indent how ever I wanted, I’d give it a try straight
away.

Peace,
Phillip

[josh]

Phillip K. wrote:

Joshua M. wrote:

OK, there we go, good-bye Markaby…

Malline is very similar to Markaby. I’ve been working with it the past
few days and have run into a couple of problems, but the developer is
very responsive. www.malline.org and there’s a Trac at dev.malline.org.

Peace,
Phillip

Thanks for the hint, I forgot to check this one out… Seems quite OK,
but somehow I don’t like stuff like

self << _‘some output’; << br

(or whatever)… Doesn’t seem much more beautiful than normal ERB…

So I guess I’ll stick with ERB for a while…

[josh]

…for the most part it should be as straight forward as

_ ‘some output’
br
_ ‘some more output’
div.some_class do
p do
_ ‘Your content here’
end
end

I still very dislike the underscore for normal strings…

[josh]

Joshua M. wrote:

I still very dislike the underscore for normal strings…

I do, too. But since it’s a function call, it has to be something. I
think you can also use txt or txt!. Between the two, I actually prefer
the underscore.

For me, it’s the lesser of all evils. Just looking at all of that ERb
code makes my eyes blur.

Peace,
Phillip