Performance of Markaby, XmlMarkup, Haml Haiku and Malline?

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. :wink:

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

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

<div id="example-1" class="example">   <p class="hello">     this is an example   </p> </div>

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.

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.

Ryan Bigg 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. :slight_smile:

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

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.

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:

  <p>Greetings, <a href='...'>User</a> !</p>

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! :slight_smile: CSS quite the way it was meant to be!

> 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.

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. :slight_smile:

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

Joshua Muheim 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:

  <p>Greetings, <a href='...'>User</a> !</p>

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! :slight_smile: 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

<p>Greetings <a href="/users/2">arc</a>!</p>

Do you mean something like:

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

which yields

<p>Greetings <a href="/users/2">arc</a>!</p>

Now do the same for

<p>Greetings, <span class='some_class'>User</span>!</p>

:wink:

Tim Uckun 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 :wink: ). 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 Muheim 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))}!

<p>Greetings, <span class='some_class'>User</span>!</p>

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, <span class='some_class'>#{user.name}</span>!

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.

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.

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.

> 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 :wink: ). Also, a sufficiently smart text editor should be able to do this for you.

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 :slight_smile:

Joshua Muheim 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

Tim Uckun 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 :slight_smile:

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

Phillip Koebbe wrote:

Joshua Muheim 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... :wink:

Joshua Muheim wrote:

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... :wink:

I'm by no means an expert on Malline, but I don't think you have to use that style all too often. There are places where helpers generate strings (like in Markaby) that you have to handle like that, but 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

If you haven't yet, take a look at the comparison of the Beast views (http://www.malline.org/beast). That should give you an indication of it's usability.

Peace, Phillip

...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... :wink:

Joshua Muheim wrote:

I still very dislike the underscore for normal strings... :wink:

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