What I dislike about TT isn't TT, but its fanboys. They claim that it allows you to seperate content from presentation from logic and that nothing else in perl does. What rot! Wanna display a table of data? You need logic in the template to loop over the data. Wanna display an arbitrarily sized table with arbitrary headings? You need a *lot* of logic in the template.

The fanboys also argue that TT is easy for non-programmers to use. Sorry, but my experience differs. I wrote some nice functional templates which worked, handed them over to a designer to make pretty (and bear in mind that TT is alledged to be designer-friendly), and he promptly broke them all.

Given that you can't get away from putting logic in the template, why bother inventing a whole new mini-language, when you could just use perl? The fanboys say that that means you put too much code in the template. Not true, unless you're an idiot. Perl has these things called "modules".

Having said all that, I do use TT. For *some* jobs, it's the right tool. For other jobs I use it grudgingly because it's the company standard and it at least has the advantage of being well known.

My experience of introducing inexperienced programmers and Web developers to TT is that they find its dot notation easier to deal with than Perl's arrows and curly braces. The ambiguity caused by simpler syntax doesn't cause these people as many problems as the simplicity solves.

My experience with trying to explain logic to non-programmers fits yours: I had trouble explaining HTML::Template's TMPL_IF construct to one HTML designer. I think TT's syntax helps some junior programmers, though.

Your preference for using an existing language (Perl) over a mini-language (TT) fits the philosophy of Ruby's Rails project. I don't have a strong preference for either approach, but I think a separate templating system suits me better. As ever, choose the technology that suits not only the problem, but also the people who will solve it.

The fact that a non-programmer could fail to use TT successfully does not mean that it isn't easy for non-programmers to use TT. It means that it is possible for non-programmers to mess TT up.

I talked about this in Re (tilly) 6: Code Critique. The problem is fundamentally an issue of figuring out how you'll cooperate. If you just threw a bunch of templates over the wall to the designer, I'd expect a bad result. If the necessary communication and understandings were worked out for cooperation to happen succesfully, good results are possible (and many people have achieved them).

Snails are still slow, even when you compare them to slugs.

I don't agree with this. Speed is relative, and snails are only slow if you have something else much faster to compare them to, like a jet engine. Embperl and Apache::ASP are arguably significantly faster, but not a lot faster. Raw print statements are a lot faster, but sacrifice most of the functionality that leads people to a templating system in the first place.

Regarding the code for handling tables in a template, this is what plugins are for: you write the tricky part in Perl, and the template author still gets to control things like how many columns there are. A good HTML coder should be able to deal with simple loops and conditionals. I used the table plugin and date plugin successfully for this kind of thing.

Of course you could also write a module for this and use it from Mason or Apache::ASP, but I find that people don't usually do that when it's so easy to put the perl code right in the template.

Not every HTML coder in the world can handle templating. I've had nothing but success with TT, but I can imagine some people just won't get it. The key things that I did that helped were to provide documentation of the data being passed in (as oppposed to handing them sample templates to pretty up) and to give them a simple template tester that allowed them to type in test data (in the format that the real app would send) and run it through a TT template. This let them experiment easily.