Hacker News Reader

Comment by riffraff | Hacker News Reader

could you expand on why is it that you favor it?

I ask because I like the idea of a stateless xmlish template language, but I wonder what this offers over the zillion existing solutions.

"Separates view and business logic" and "enables DRY design" are valuable goals, but most template languages have them.

View on HN

Good question. A few reason:

1. Heist allows you to define your own HTML/XML tags in the host language (Haskell in this case). This means you're only dealing with (an extended) XML document when doing layout and design so all the normal XML tools still work.

2. Some popular template engines try to separate logic and design but end up letting you cheat a little. Any time you want/have to cheat and put logic in the template, it really was a shortcoming of the template engine. In Heist, you can't cheat but you never want to.

3. The reason #1 and #2 work is because Heist's "recursively applied splices" is just the right abstraction. My HTML templates end up looking just as pretty as well factored Haskell code. Heist makes the perfectionist in me happy.

In short, I would say you're right here: '"Separates view and business logic" and "enables DRY design" are valuable goals, but most template languages have them.' But just because most template languages have these goals doesn't mean they've achieved their goals. Heist, in my experience and opinion, does achieve these goals.

From their compiled heist docs [1]:

There are two things that compiled Heist loses: the ability to bind new splices on the fly at runtime and splice recursion/composability.

I haven't checked or read the doc thoroughly, but if it's what I think it means - all we get is hierarchal splices. Which is still a lot, but it's not quite as magical.

[1]: http://snapframework.com/docs/tutorials/compiled-splices

We still keep some of the magic by allowing you to run the old "interpreted" style splices at load time. These don't have access to dynamic data, but they do have recursion/composability. This combination retains most of the power while allowing a huge speed increase. It just means that to take advantage of both you have to structure things in a certain way.

At this point it seems to me that this structure also ends up being a desirable one for organizational reasons. But the jury is still out as far as whether there will still be reason to want more. We're aware that there might be good reasons to support this extra power and I have a pretty good idea of how it would be implemented. But I want to get more people using it in the real world before we address that issue.

I'm not him, but personally I like it because html is actually a pretty good language for markup. I find any custom syntax to be worse than just html, and you lose the ability to use standard html tools, syntax highlighting, etc.

And as much as it may be possible to separate logic from presentation in a typical PHP/ASP/JSP style template, I've never actually seen it done. When something is made awkward, people tend to choose the more convenient approach, so you see an unfortunate amount of nested loops and conditionals in most templates. Being able to have designers write templates by simply telling them "anywhere you want dynamic content, just make up an appropriately named tag for it and pretend it is part of html" is really nice.

Right on here. Exactly how I feel.

Generating HTML is really the whole point of a web framework so it better be awesome at doing so. Heist does this well.

thank you both, but I think I failed to express myself: what I meant to ask is: how is this better than other xml based templates, such as wicket, TAL, Kid, Genshi etc.

I would be led to understand, given your comments, that Heist does not allow control structures in the templates, but looking at some snap code[0] it would seem iteration is right there. Which makes sense I guess.

Or am I missing something, and there is a fundamental difference between Heist's

    <posts:reverseChronological>
      <a href="${post:url}">stuff</a>
    </posts:reverseChronological>

and, say, Genshi's

   <a py:for="post in reverseChronological"  href="${post:url}">stuff</a>

Is the difference, and thus your preference, in the fact that posts:reverseChronological works more like a function call taking the content as argument, rather than a "classic" loop?

[0] https://github.com/snapframework/snap-website/blob/master/bl...

>how is this better than other xml based templates, such as wicket, TAL, Kid, Genshi etc.

I don't think it is. To me it is just the haskell template engine in that style (which is the style I prefer). That style of template engine is the minority, so most comparisons are vs either mixed style (php/asp/jsp/rails) or vs custom syntaxes (mustache, haml, etc). What is good about heist certainly applies to similar template engines like lifts, zopes, etc.

I think the difference is that Genshi's py:for appears to be a construct provided by the template system. In Heist, posts:reverseChronological, like you say, is just a function call. Looping doesn't happen in the template, it happens on the Haskell side. Genshi has to have a different construct py:if for conditionals. Heist doesn't need another construct. A function call serves both purposes. This has several positive effects. First, it means Heist's core is simpler since it only has one fundamental abstraction that has enough expressive power for implementing all of Genshi's special case keywords. And second, I think it gives a clearer separation between logic and view.

Reply on news.ycombinator.com