XSLT is the Spawn of Satan

by Charles Miller on February 12, 2002

Does anyone out there, anyone have an example of a non-trivial application that benefitted from the use of XSLT more than it would have if developers had used another language to manipulate the XML?

XSLT is almost the perfect example of the product of architecture astronauts. I have this vision of the working group's deliberations as they came up with it. They'd have started off with a pretty simple premise: Let's write a language to convert one XML document into another XML document. Good starting point. There's lots of benefits to having this. OK. There's a need for this, lots of people would find it useful.

OK. Now wouldn't it be cool if the language itself was valid XML? Why? Because... er.. because then you'd be able to make an XSLT document that takes another XSLT document and converts it into XSLT! Wouldn't that be cool? Er, yeah, sure. And it'd also make it impossible to read, and change even the simplest operation into a morass of tags and attributes, just so we can get some weird, inflexible kind of code reuse that's a total bitch to manage compared to the alternatives.

Meanwhile, despite the whole move to completely separate logic from presentation so web designers can write templates, and coders can write the code that fills them, let's write a language that makes template and logic inextricable.

But... but doing everything in XML is cool! In the future, everything will be in XML. Your shorts will be in XML! We'll do it that way anyway! Oh, did I mention that we have to do it this way, because there's no way to take two documents as input, and merge them into a single output document? That would make things far too complicated. It's so much easier to write an XSLT template that takes the first document, and uses it to produce a new template that you run the second document through. Isn't that so much better? Of course, it's dog slow to code because the programmer has to wrap his head around all these nested meta-templates, and dog slow to execute because the processor has to recompile the intermediate template every time, but it makes things so much more conceptually clean!

Oh, and Bob here's a professor, and he's really into functional programming and recursion. Let's make it a functional language. Why? Well, because functional programming is really clean and neat, and we all studied it at university and haven't been able to use it since! Oh... you mean what do we tell everyone else? Well, I guess if we did that, then an XSLT processor would be able to parse lots of bits of the document at the same time, rather than having to go from one end to the other and saving state along the way. What do you mean, "there's probably a very good reason you've not used functional programming since University"?

Practical benefits? Oh, I'm sure it'll speed things up in the long run, even if it means we'll make simple things like a for loop take up four pages of coding, force any non-trivial operation to use heaps of recursion, and generally make programming in the language an exercise in gritting your teeth and fighting through it. For the moment, we'll just ignore the fact that the entire trend in web application programming has been towards sacrificing straight-line speed of applications in order to shorten development time.

Let's face it. In pretty much every language, coverting an XML document into an object graph is trivial. Massaging objects to come up with a document is trivial. XSLT takes these two trivial operations, and makes them intensely painful. The whole language, the whole specification, every single book written on the damn subject needs to be burned, page by page. I'll volunteer with the flamethrower.

Previously: What's Wrong with OPML

Next: Thu, 14, Feb 2002 11:24:00 AM