
Open Letter to XSLT Fans - saurabh
http://www.snoyman.com/blog/2012/04/xslt-rant.html
======
gioele
A master of XSLT once explained me that if your XSLT files are longer than 100
lines, you are doing something wrong.

For years I struggled to create 100-line XSLT files; it looked impossible.
Then I realised what the problem was: I was trying to convert the source tree
into the result tree in one big step. XSLT can do that, but it is not meant to
do that and it is just bad software engineering. What I should have done (and
I started to do) is to divide the transformation in smaller uniform
transformation steps: for example, in one case I ended up with this series of
XSTL files, each one taking care of a single step in the transformation
pipeline:

* cleaning (remove duplicated and empty nodes);

* completion of partial data (where I go, fetch missing data and use it to make the original data more homogeneous);

* grouping and reordering (twist the data around to make it more similar to the destination format);

* data transformation (where the individual pieces of data are transformed into separate nodes in the destination format);

* layout integration (fill the holes in the layout template with the missing data).

Each file ended up being very small, readable and easily maintainable. The
much shorter xpaths used in the templates are a clear indicator of how much
better that project has become. Before the split I was doing things like
fetching the missing data while putting the already transformed data in the
layout template; that was forcing me to transform the newly retrieved data in
place before being able to use it. It was a mess. It was a mess because I was
not following one of the underlying and unspoken assumption of XSLT. Isn't it
the same with any other language? Will an Haskell-based tree transformation
language prevent me from writing huge single-file many-purposes-in-a-single-
function spaghetti code?

That said, I do not like articles like this that do not explain _why_ they do
not like something and do not give examples of what is wrong and how it should
be instead.

------
zdw
XML, and surrounding technologies like XPath, XSLT, Schematron, RelaxNG, etc.
by extension, are extremely useful as data storage and validation languages.
If I was planning to keep structured data around for a long time on disk, and
want to make sure that I didn't have garbage stored, I'd definitely want it in
XML, with a fairly strict schema to validate that data.

If you're writing an API that works with files (not an over the wire format),
and you don't want to be locked into any one language or toolset, XML is
pretty hard to beat. Being able to write just one XSLT file, and have it
processed by any compliant processor is pretty impressive - no other
templateing format works that way.

The problem for most people is that they never touch those other technologies
that make XML great, because they're looking at basic data serialization, and
don't care so much about validation and transform. Most web technologies fall
into this category. Any tool can and will be abused - how many of us have seen
a monstrous unmaintainable Excel file that performs a task that would be much
better done in a scripting language?

TL;DR: XML tech has it's uses, but it's very frequently abused.

~~~
doc4t
Although I find XML to be much too cumbersome and bloated for any practical
situation I can still understand the technical arguments in favor of using it.
What I don't understand is why anyone would choose XSLT over a full featured
scripting language like PHP, ASP, JSP or similar. As you obviously have much
more experience than I in this field can you provide an example where XSLT
would be the preferred choice?

~~~
silentOpen
[http://www.khronos.org/registry/webgl/extensions/OES_texture...](http://www.khronos.org/registry/webgl/extensions/OES_texture_float/extension.xml)

No dynamic server-side templating language, easily transformable to other XML
formats (docbook, atom (see front page of registry)). If the user/client has
libxml, the processor command is already installed. The specifications are now
provided in an application specific format that is language-agnostic instead
of manually maintained ad hoc HTML. The extension registry index page is now
automatically generated into static HTML instead of manual HTML+JavaScript for
sorting the lists.

Finally, the restricted power of XSLT is an advantage for this application vs
PHP, ASP, or JSP. If browsers actually implemented web technologies like XSLT,
sending XML specs and generating HTML on the client side with cached XSLT
would save bandwidth.

~~~
aurelianito
How is XML + XSLT better than JSON + JavaScript for generating the view in the
browser?

Note: You can generate HTML using JavaScript but it is not needed. You can
manipulate the DOM to change what the user sees.

~~~
silentOpen
It is easier for crawlers to ingest.

~~~
chris_wot
Can you prove this?

------
agwa
This post starts with a legitimate gripe about XSLT being classified as a
"functional" language but then it devolves into a merit-less rant. It makes me
wonder what the author uses XSLT for. It sounds to me like he's trying to use
it as a general-purpose language. It is not. It's an incredibly single-purpose
language for translating one XML document into another, and it makes no
pretense of being otherwise. I've been using XSLT in large, multi-file
projects for years (so I'm exactly the kind of programmer who "likely knows
[he's] right"), and there is absolutely no substitute for what it does.

~~~
masklinn
> It's an incredibly single-purpose language for translating one XML document
> into another,

In the same way ColdFusion is "an incredible single-purpose language for
translating databases into web pages": it's not, the difference is that XSLT
has no alternative whereas CF has a billion.

> and there is absolutely no substitute for what it does.

That's the issue, XSLT is not "incredible", there's just very little
alternative.

~~~
sk5t
The parent post does not describe XSLT as "incredible," but rather as
"incredibly single-purpose."

------
droithomme
Wow, I wasn't aware there were any XSLT "fans" out there. I wonder where the
author has been hanging out to find them.

~~~
simonw
The BBC used to use XSLT a lot for templating web pages, and had a small
cluster of XSLT adherents working for them. I believe they've mostly switched
to PHP templates now.

~~~
guard-of-terra
"I believe they've mostly switched to PHP templates now." Oh my god make me
unknow this.

(XSLT does actually have a standard, syntax checking and built-in context-
sensitive quoting)

~~~
reinhardt
Reminded me of <https://xkcd.com/224/>: "honestly, we hacked most of it
together with perl"

~~~
SkyMarshal
_> My god, it's full of car's!_

lmao. Thanks, hadn't seen that one.

------
olalonde
Weird, I nominated XSLT as my "most hated language" in the "What's your most
hated language" poll a few days ago and got a few down votes. Now, this rant
against XSLT is on the front page... Go figure!

~~~
mindcrime
In a world where RPG/III, RPG/400, RPG/IV, etc. exist, _how_ can XSLT be
anyone's "most hated language?" :-)

All joking aside, I like XSLT just fine, as long as it's use is limited to
exactly what it's good at: transforming XML documents from one schema to
another. Yes, it's verbose if you write it by hand, and yes it would be nice
to have something with all the power of XSLT and with a lighter syntax, but
XSLT is hardly the worst thing around.

~~~
archangel_one
I think it's probably the worst language I've had the misfortune of having to
write anything in. Certainly it was the one I enjoyed the least (even slightly
less than Fortran 90 which was somewhat of an achievement), and I think it
wins my "most hated language" because of the intersection of awfulness and the
nonzero chance that I'd have to program in it. While there are almost
certainly worse languages - COBOL certainly appears to be one - there's
effectively zero chance that I'll ever write anything in them, hence they're
more of an amusing curiosity than something I can hate. Whereas I've had to
spend interminable days on XSLT in the past and unfortunately I can't say for
sure that I'll never have to again.

~~~
batista
Your only argument is "I had to use it and I hated it". Hardly an argument.

~~~
andrewflnr
We're talking about hate. Do they need an argument? Considering we're talking
about hypothetical answers to an _opinion_ poll, I think not.

~~~
batista
_> We're talking about hate. Do they need an argument?_

Blind hate is hardly something desirable. I'd say, yes, even hate needs an
argument.

~~~
archangel_one
I would at least like to claim that it wasn't blind hate; I have used XSLT
before so it's partially sighted at least. And really, it's tongue in cheek.
XSLT is a programming language, "hate" for such a thing only really goes as
far as "I don't like working with it and hope I don't have to again".

~~~
andrewflnr
Right. For our purposes, you no more need an argument to hate XSLT than you
need one to hate chocolate. You tried it and didn't like it. Case closed. ;)

------
cies
This guy is hilarious:

"Oh, and the fact that you can call a language functional when it lacks first
class functions makes my eye twitch. I'm tempted to upload a video of my eye
twitching just to prove it."

Anyway, he's the initiator of Yesod, a screaming fast, type-safe web framework
in Haskell. Some one called him the 'type safe version of DHH' last month :)

------
ShabbyDoo
XSLT is miserable, but isn't this old news? My issue is that most real-world
transformations require look-up tables, calls to other systems for derived
data, etc. The XSLT extension format is no fun at all. Sadly, I have yet to
have seen a good, general-purpose framework-y library for sort-of declarative
transformations. I suspect that, because most transformation code exists to
achieve interoperability between systems, the problems at hand involve
impedance mis-matches which are inherently yucky problems.

Anyone seen any good schemes?

~~~
masklinn
> Anyone seen any good schemes?

I've been meaning to look at HXT, I've read it had something like that, but I
have not needed to transform XML in a long time so it's fallen by the wayside.
On the other hand, TFAA qualifies himself of "Haskell programmer" and does not
use HXT so maybe it's not that good.

An alternative I've thought about (but not implemented on grounds of having
absolutely no need for it these days, as noted above) is implementing what I
consider the good part of XSLT (tree transformation via template matching
through XPath selectors) in Python on top of lxml. Something akin to Flask,
where the app would be a group of templates, and the routing would be a
sequence of XPath assertions (instead of http PATHs + methods). Along with a
few helper functions or methods (to easily recurse into the rest of the tree),
this ought materialize most of XSLT's strengths in a general-purpose language
(making extensibility trivial), and template groups would improve modularity
significantly.

~~~
justincormack
You could call it "xslt the good parts".

~~~
masklinn
Pretty much.

------
taftster
Some time ago, I thought XSLT was quite interesting and potentially powerful
with regards to its browser integration. XSLT, to me, represented the first
attempt at truly separating data from layout. Even to this day, with all the
'div' based layouts and such, nothing completely and totally separates the
data and view tiers in a web layout quite the way that XML with an XSLT
stylesheet did.

Early browser bugs probably caused more harm than good for XSLT adoption. XSLT
was available in browsers almost from the beginning, more powerful (at the
time) than any other client side (javascript) solution. Too bad it didn't get
off the ground some more, it might have actually changed the way we work
today.

Yes, it's too verbose, and probably doesn't deserve the title of "programming
language." But, it's a pretty powerful idea if kept in the scope for what it
was invented; transforming one schema to another, with options for
transformations occurring on the client or server side.

------
knewter
Back 8 or 9 years ago I architected and worked on a team to write a very large
and feature-rich application that depended on XSLT for a ton of UI-deriving
functionality.

I found it extremely powerful.

I have never used it again, because the power it afforded me was not worth the
heartache.

~~~
hartez
Just prior to .NET I worked on a classic ASP project that did this - the view
models were basically SQL queries with 'FOR XML AUTO' and the 'views' were
XSLT stylesheets.

For getting simple data up on a web page it was fantastic. But for more
complex stuff it got wickedly complicated to maintain at an exponential rate.
XSLT just didn't scale (and/or we just weren't good enough at it to make it
scale).

~~~
gouranga
I still have to work on a classic ASP thing that does this. It's taken 5 years
to get 50% of it over to .Net.

PAIN. That's what it is. Just PAIN.

------
sourishkrout
The spec of XSLT2 was actually going to work this angle and move XSLT more
into a space of a general purpose language. However, lots of people in the
XSLT community realized that XSLT is made to do one thing and that's XML
tranformation. XSLT(1) did that pretty well to a certain extend. The spec for
XSLT2 never really took off and I don't think there are notable
implementations and support out there other than from the spec's leading
author's (Michael Kay) and his tool Saxon.

------
georgebashi
I started using XSLT about a year ago and had exactly the same initial
reaction - it looks ugly and verbose, it's difficult to debug, and badly
written code is almost impossible to understand.

A (difficult!) year of daily use behind me, I've found that all the above
problems disappear. People come to XSLT expecting a procedural DSL for
modifying an XML file which they can pick up in a day or two, and very quickly
their code spirals out of control as they try to twist XSLT into what they
expect. It very clearly isn't a procedural language, which is why I think it
gets labelled as functional, because it doesn't accurately fit either model.

Once you develop good code style and know the pitfalls to avoid, it's
perfectly pleasant to use. It's also significantly easier to get along with if
you use a full blown XSLT IDE like oXygen, which allows you to breakpoint, see
the call stack, and trace back which template generated a specific part of the
output.

------
josepsanzcamp
It is important that a developer is able to capitalize on each programing
language. XSLT is not a language for writing a kernel, it is only to make
transformations between XML files (more or less). If the writer of the "Open
Letter to XSLT Fans" is frustrated by your current job, maybe he has to find
another job. Is the equivalent that a ANSI C programmer critize the language
because all days are fixing bugs related to the pointers. PLEASE, BE
COHERENT!!!

------
pacaro
Without going onto the merits or otherwise of XSLT, there is another
observation...

For some reason, even on teams with good engineering practice, all discipline
goes out of the window when people write XSLT. So a dev who might write
beautiful maintainable code in any other language suddenly reverts to the
worst spaghetti style on XSLT with 1000 line functions, impenetrable naming,
nary a comment to be seen.

I know. I've been that dev.

~~~
read_wharf
Is that because most people can "see" the solution in most programming
languages, but most people can't see solutions in XSLT except by
experimenting?

~~~
pacaro
There may be some of that, especially at the beginning, but with a little
experience that phase seems to pass, it helps to be working in an environment
with a good XSLT debugger of course...

I think the fundamental issue may be more to do with a flawed distinction
between read "code" and just a "stylesheet / data transform"

------
Uchikoma
Dear Michael, please don't insist on calling program languages bastard childs.

Sincerly, someone who understood that programming lanugages are tools.

------
narrator
I used to use XSLT for a lot of things. I switched off it because it's just
too damn slow and can be a total brain melt to do complicated stuff in that's
fairly easy in just about any other programming language. The few things I
liked about XSLT can be done fairly easily with Scala's pattern matching.

------
X-Istence
I've used XSLT in the past, mainly to do client side transformations, so send
the browser XML, with a XML stylesheet tag and have the browser use the XSL to
do the transformation.

At the time the only browser that didn't support it correctly was IE, but
after some small work arounds it worked pretty well. The downside being that
inserting ad networks didn't work because there is no document to .write() to
being XML, and the fact that you had to host a valid DTD and your document
would get verified against it each and every time.

The other big issue was that you have to write a lot of boiler plate code to
get it to do what you want it to do, with a lot of recursion and the like.

------
jlogsdon
I remember when I found XSLT. I fell in love with it... until I started using
it in real world situations. Unless I wanted to pass page content with
paragraph or line break tags already added I had to use a 50+ line recursive
nightmare.

I do not miss it.

------
neovive
Many higher-education open source software utilize a Java / XSLT stack (e.g.
JA-SIG uPortal, Sakai) and I agree that XSL can be quite tedious and verbose.
It's definitely the type of language that, if you work with it just "once in
while", is very frustrating. If an XSL file it's not broken down into
manageable templates it becomes very hard to follow. If you're not so lucky
and have to deal with extremely large XSL files, it's easier to just give in
and purchase one of the available XML/XSL IDE's. There are a few good ones and
they do save a lot of time. No need to struggle through it with a plain text
editor.

------
pinaceae
i don't get the anger or argument. xslt is a templating language, nothing
more, nothing less.

it is awesome as a cross platform solution for transforming xml into some
other stuff. for anything else - why on earth would you use it?!

i really enjoy playing with it, generating complex html out of xml. things
like grouping with the muenchian method are the defintion of nerdy fun for me.
to this day i have no idea what went on in steve muench's head to come up with
that small snippet of code. i just love him to death for it. i pretty much
build a career on top of it, as a lot of other coders never groked it.

------
krollew
It's only programming language I know and is completely useless (since there
are better choices) and totaly enoying. I see I'm not alone. :D

~~~
mdaniel
I feel that "completely useless" is a bit harsh. For one thing, it is damn
near ubiquitous (when one has a system that is already trafficking in XML).

~~~
krollew
I think I can create much easier to create and much more readable code in any
flexible language with nice XML support like perl or PHP. I think it'd be more
powerful since as far as I remember XSL lacks some stuff.

------
tingletech
I'm supposed to not call XSLT functional because some dude just called me a
bastard for being an XSLT fan? Yea, screw you to buddy, I hope you eye keeps
twitching.

