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.
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.
Generating HTML is really the whole point of a web framework so it better be awesome at doing so. Heist does this well.
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...
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.
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.
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
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.