Have you benchmarked recent XSLT solutions for this pre-conceived "slowness"? They are very very fast these days...

As far as the advantages, I'll paraphrase Robin Berjon on this... The advantage he sees of using XSLT is that it's a very well thought out system, with a lot of history (DSSSL) behind it. With XSLT you aren't constrained by flat structures like many templating systems - and by that I include hierarchies where you have to "manually" iterate over the tree. With XSLT you just declare what bits of your data are meant to look like, and run it. But it's more than that... With XSLT you are not creating text. That is what every single other perl templating solution does - it takes some data and a template and generates text. This does not lead to efficient pipelining (which is a technique that most people in the perl world aren't really familiar with, because of this weakness, but a very useful technique nonetheless). With XSLT you take some a data structure, and a template which describes a new data structure, and you get a data structure at the end of it. Not text (and not really XML either - you have to think outside of that box :-)

Oh, and one other benefit: multiple vendors.

Matt (with a v.fat C.V.) ;-)

I haven't benched the latest round of XSLTers, but the performance on XSLT has historically been pretty abysmal. Most of the time people (read "Cocoon") say they have solved the problem by caching the output, but not all output can be cached. I doubt that XSLT can be very fast when actually parsing XML (for the data and the style sheet), so presumably the biggest speed wins would come from caching the stylesheet as perl code, and from generating the data in a perl data structure that the XSLT processor understands instead of actual XML (thus skipping the parsing step). Are we there yet? And if we are, aren't we kind of re-inventing the wheel? Perl doesn't need XML to make generic data structures.

Your point about not being constrained to a linear mode is actually one of the things I hold against XSLT, because all of the HTML monkeys I know like to think about page design in a linear mode. They don't want to specify a style for the product price; they want to write some HTML and say "the price goes here." It's just more intutitive to non-programmer types.

I can see value in pipelining for working on data, but I would do all of that data mangling before I get to a page generation stage, so the template tool itself doesn't need to support it.

Anyway, I have happilly used XML for other things and I don't usually take stabs at XSLT, but since he asked for opinions... I try to keep my preferences from coloring my templating guide too much (which now desperately needs an update, with new versions of AxKit, TT, Apache::ASP, etc. out).

Forget about Cocoon, and caching. XSLT is really really fast. Both MSXML4 and LibXSLT are simply incredible performance-wise, even if you parse every time. But then I guess we really need to do some sort of proper benchmarking to prove that :-)

(not with AxKit though - it's internals are large, and would hide any performance difference against other solutions - what you should look at is a pure TT solution vs a pure LibXSLT solution, or something. I wish I had time to do the benchmark :-)