
XSLT is a failure wrapped in pain - armenb
http://harmful.cat-v.org/software/xml/
======
grndn
The problems that XML and XSLT address have not gone away. It saddens me when
the XML-hating JSON community starts reinventing solutions that have all the
same issues of bloat and complexity (see JSON schema, Collection+JSON, Siren,
etc).

I would not be surprised if someone soon announces a "JSON Transformation"
tool that can convert one JSON schema to another. Followed shortly by a
standard for JSON namespaces so you can mix different schemas, a standard for
binary JSON, a standard for JSON-encryption, and so on.

"Those who cannot remember the past are condemned to repeat it."

~~~
Arwill
Its a generational thing. Programmers grown up on JavaScript will prefer JSON.
Its not a unique phenomenon. My guess is the noSQL was born out of fact that
many young programmers simply don't know how to write SQL, if they don't
know/want to use SQL and rely on ORM mapping alone, then they can as well do
away with SQL databases too.

~~~
marcuskaz
> Its a generational thing. Programmers grown up on JavaScript will prefer
> JSON

Not really, JSON is a simpler format with better parsing built-in for most
languages. It is easier to use for programmers and performs better across the
network.

This is as true today as it was true 7-years ago when I wrote this article:
[https://mkaz.com/2007/03/02/goodbye-xml-hello-
json/](https://mkaz.com/2007/03/02/goodbye-xml-hello-json/)

~~~
bkeroack
And YAML is a better JSON with comments and no need to balance braces.

------
nly
What's with linking to an old "XML sucks" page with no content, insight or
original thought? Is it bash <whatever-was-on-the-homepage-a-few-hours-ago>
time?

On XSLT: find something that fills its role completely, with the same level of
tooling, and then have a rant about inferior tools being popular, until then
it doesn't really matter if it sucks.

~~~
hobs
If you refresh HN regularly, you will see that really often. People are just
gaming the community for a few upvotes or views as far as I can tell.

I see this timeline all the time: 1\. User posts article about xyz technology
2\. User posts article negating post 1 3\. Most boring shitstorm every occurs
4\. karma karma karma

~~~
ramped
I think you just described every discussion medium on the Internet.

As a reddit refugee, I was hoping for a little more on HN.

------
VMG
Since it is the hot topic of the day, let me add this perspective:
[http://www.snoyman.com/blog/2012/04/xslt-
rant.html](http://www.snoyman.com/blog/2012/04/xslt-rant.html)

Quote

 _> I'm not even talking about the hideously verbose syntax, or the completely
obtuse data model. The fact that you can't know what any single line of code
does without reviewing every other line in the program makes this language an
abomination._

~~~
craigching
That link is on the page ;)

------
robert_tweed
One quote sums it up:

“XML is simply lisp done wrong.” – Alan Cox

It's not that XSLT isn't useful in some situations. It is. It's not that
clean, simple and efficient XSLT is impossible. It is, but it's hard.

The fact that it isn't Turing complete can be a good thing. It can also cause
a lot of headaches.

The main problem is that XSLT as designed and as implemented is an over-
engineered god-awful mess. XSLT 2 was a huge improvement, but nobody
implemented it, or they maybe only implemented bits of it in nonstandard ways
(MSXML), so none of the better parts were reliable.

The idea of XSLT was sound and XPATH was pretty nice, but anyone who thinks
XSLT is "good" probably has never worked on a large XSLT-based project (one
where XSLT files routinely include other XSLT files and XML documents
routinely link to other XML documents via xlink).

People say complexity gets out of control with OOP. Those issues pale into
insignificance compared with rampant pattern matching split over many files
when you have dozens of different schemas and are dealing with massive
document graphs (with the occasional cyclic edge for good measure).

Good luck trying to reliably predict results in advance, or add any sort of
control-flow logic to deal with edge cases without resorting to hard-coding
and unrolling recursion.

~~~
sergiosgc
XSLT is Turing
compete:[http://www.unidex.com/turing/utm.htm](http://www.unidex.com/turing/utm.htm)

It is a functional language, probably one of the reasons people don't like it.

~~~
robert_tweed
To quote Haskeller Michael Snoyman (linked elsethread):

    
    
      Please don't insist on calling your bastard child of a language "functional."
    

It's a declarative language. It's functional language if you squint at it,
sort of. Maybe. It certainly doesn't fit with the most broadly acceptable
(stricter) definitions of what a functional language is.

The biggest problem, with XSLT 1 at least (and that's primarily what I'm
talking about because that's what exists in the wild), is that the output of a
template function is a string, whereas the input is a node tree. So to get
generalised recursion or perform function composition over the input data, you
need to do some evil tricks.

To give the impression of Turing completeness, you need to first parse the
input stream by splitting it up into strings and then call functions that
perform string processing, which means you can no longer use xpath, or any of
the things that really make XSLT. At that point you're not really writing XSLT
anymore, you're doing simple recursive string processing using XSLT as a
horrendously overweight and improperly-equipped wrapper around your native
string libraries.

Incidentally, I don't accept the linked article as a proof of Turing
completeness, since it only implements some trivial programs using Turing
machines. That's not the same thing as proving equivalence with a universal
Turing machine. However, others seem to have done it, presumably using tricks
such as string processing, or ignoring the input altogether.

You could for instance, recreate Conway's Game of Life using pure XSLT, but it
wouldn't contain any actual XML transformation code and all the state would
exist in the running XSLT program, not the XML document. It would also blow
the stack as most XSLT engines don't support tail recursion and there's no
other way to loop indefinitely.

What you certainly can't do is have one function that outputs a set of XML
nodes and another function that has a for-each that consumes that set, or have
the ability to run apply-templates over it. That is nothing like functional
programming.

------
bambax
Rather than singing the praise of XSLT (which I love) I'll show an example:
this tool transforms any rich text to markdown:

[http://markitdown.medusis.com](http://markitdown.medusis.com)

It's about 30 lines of XSLT that run in the browser. [Edit: it's not 30 lines
but 230, but I was thinking of the number of "rules" (templates) of which
there are only 29.]

There are very few other tools of its kind and I don't think there exists any
client-side, with the same simplicity. This attempt for example

[https://github.com/domchristie/to-
markdown/blob/master/src/t...](https://github.com/domchristie/to-
markdown/blob/master/src/to-markdown.js)

is about 180 lines of JS, is incomplete, doesn't work with many special cases,
etc.

There is no better templating language than XSLT; every other templating
approach (in PHP or Python on the server, in JavaScript on the client) feels
like a horrible kludge once you've experienced XSLT.

Yes, XSLT is practically dead, that's a fact. But we should be very sad about
it, instead of dancing on the coffin like the OP with its stupid quotes.

~~~
crdoconnor
[http://markitdown.medusis.com/xsl/html2mk.xsl](http://markitdown.medusis.com/xsl/html2mk.xsl)

It looks like 234 lines of code to me.

>This attempt for example [https://github.com/domchristie/to-
markdown/blob/master/src/t...](https://github.com/domchristie/to-
markdown/blob/master/src/t..).

Is badly written, but still written in a better language. They're using
regexps to parse HTML (omfg!), but that kind of nastiness doesn't excuse XSLT
as a language.

>There is no better templating language than XSLT

Except mako, jinja2, django templating language, liquid, etc.

~~~
bambax
You're right, it's 230 lines; I updated my post accordingly. I wrote the thing
3 years ago and remembered the number of rules (templates) instead of the
number of actual lines. But a line's a line, so I was wrong.

"written in a better language" doesn't mean much, however. A better language
for what? I'm not picking on JavaScript, which I love and use every day; but
templating in JS versus XSLT is crazy.

The templating languages that you mention are, in my opinion, extremely
complex and very unpalatable; and they only work server-side.

But that's all a matter of taste, I guess. What I don't understand is why so
many people go out of their way to declare their _hate_ of XSLT (and all
things XML), especially now that XSLT is all but dead...?

~~~
crdoconnor
>"written in a better language" doesn't mean much, however. A better language
for what?

For general purpose programming, which is what transformations eventually end
up requiring. XSLT isn't java or javascript. It _theoretically_ can do
everything that those two can do, but we both know in practice that once you
don anything sufficiently complex in XSLT it will become horrendous. Even the
biggest proponents of XSLT won't argue that you should put business logic in
there (I hope, anyway).

>I'm not picking on JavaScript, which I love and use every day; but templating
in JS versus XSLT is crazy.

Because?

>The templating languages that you mention are, in my opinion, extremely
complex and very unpalatable

What??!? I can get web designers with no coding experience to edit them! Try
doing that with xslt. They're that simple! Not only are they conceptually
simpler, they are _mathematically_ _provably_ simpler due to their being non-
turing complete.

>and they only work server-side.

Am not a client side developer so I don't know what the state of the art is in
client side templating languages, but there are a few that look ok (dust,
jsrender, handlebars...).

>But that's all a matter of taste, I guess. What I don't understand is why so
many people go out of their way to declare their hate of XSLT

Because they have spent time debugging it and know that every second they
spent doing that was both painful and unnecessary.

If you don't understand the pain it might mean that you don't even realize
that the same pain you felt debugging it wasn't actually necessary.

My sincere hope is that all the people who create business critical XSLT
abortions will stop doing it so I won't ever be called in again to fix what
they did. That's why I'm passionate in my XSLT (and XML) hate.

~~~
bambax
> _the same pain you felt debugging it_

XSLT is "right the first time"; I have had to do corrections and evolutions
but very rarely (never?) have I had to hunt for a weird unexplained behavior.

Of course I have seen horrible XSLTs, but horrible is in no way limited to
XSLT (the only thing that's XSLT-specific is when people try to do imperative
programming in XSLT).

I'm currently trying to make sense of a database model where every. single.
property. is a flag in just one table (isClient, isProspect, isActive,
isAForeigner, isMale, isFemale, etc. etc.)

No XSLT involved whatsoever. Big pain.

------
geonik
Those who rant about XML and XSLT know nothing about what they talk about. 50%
of our server's behavior (200,000 Java LOCs) is orchestrated declaratively by
a small number of XML files that use around 30 custom namespaces. These are

1\. parsed on server startup for setting up persistence, business rules, REST
endpoints etc

2\. transformed by XSLT to a) produce nice HTML documentation, including DOT
class diagrams b) generate Java source code c) validate declaration integrity
and cross-referencing

With the right XSDs, IDE support is excellent (auto complete for everything).
Take the time to learn it, apply it according to your needs, and reap the
benefits- in the long run, maintenance work is down by an order of magnitude.

~~~
moonshinefe
I'm afraid your argument of "It worked for us" and "it only uses a small
number of files with 30 custom namespaces" pretty much is the most
unconvincing argument I've ever heard.

In fact, the latter point is one of the reasons most people like to avoid XML.

~~~
geonik
"the latter point is one of the reasons most people like to avoid XML"

And these are exactly those who will never "get" that XML is much more than a
data container for tree-like structures. They should stick to JSON or CSV for
that matter.

------
sly010
I will risk that this will be an unpopular opinion, but if you are having
problem with XML, you are using it to solve the wrong problem.

I understand writing XSLT and XML Schema can be difficult and I see how typing
out XML namespaces can be a pain, but every sentence about XML in that article
is a joke. Those quotes are all intended to be funny, not objective. Noone
actually brought an objective facts against XML. Because they can't. The fact
is it is widely used in many places. Anyone tell me an alternative to
serialise an object tree where you also need to preserve ordering and type
information, you need to store text longer than one line, or you just need to
store any kind of formatting information. (and yes, you can use JSON to do
that, but the resulting document will be 5x longer)

(meta: Funny quotes bashing useful technologies is the cat video equivalent of
HN. Last week's article beating OOP was the same pattern.)

~~~
crdoconnor
Objective facts:

* XML is complicated enough that its parsers are commonly full of obscure bugs. JSON/YAML doesn't have this problem.

* XML is complicated enough that its parsers can have _security_ vulnerabilities (e.g. see billion laughs for just _one_ ). JSON/YAML doesn't have this problem.

* XML is complicated enough that you can create an almost-but-not-quite valid encoding. The (already complicated enough) parsers have to deal with this and the ones that don't are considered broken. JSON/YAML doesn't have this problem.

* XML's complexity does not give you any additional benefit over YAML or JSON. Serializing/deserializing dates as strings is not a problem. It never was.

XSLT is just the shitty icing on the already crappy cake. A committee created
a disastrous turing complete _programming language_ to munge this already
overcomplicated data format.

~~~
personZ
If we eliminated everything where implementations have had obscure bugs or
security vulnerabilities, there would _literally_ be nothing left.

 _XML 's complexity does not give you any additional benefit over YAML or
JSON._

This is so incredibly wrong, on every level, that it belies belief and reads
like something you would come across on a "beginning programmers" forum. As
others have said, JSON/YAML thus far have seen limited usage (no, that
configuration file on your app is not a complex example). But as it grows
people are starting to ask questions like "Gosh, wouldn't it be nice if my
perimeter or the source system via a metadata file could validate the JSON
passed to us". "Wouldn't it be nice to be able to convert from one JSON form
to another."

And the exact same complexity is arising...poorly, and with the same hiccups
that the XML system went through.

I mean some of the comments are incredible. Like "JSON is simple enough that
errors aren't big" -> Hey, sorry that those bank transfer got lost, but it
turns out that we mistyped the account number field name and the destination
system just ate it. Json.

¯\\(°_o)/¯

Sorry that the dates are completely wrong, but all of those years of discovery
about time zones and regional settings...just make it some sort of string and
they'll figure it out.

¯\\(°_o)/¯

~~~
scrollaway
> Hey, sorry that those bank transfer got lost, but it turns out that we
> mistyped the account number field name and the destination system just ate
> it.

The JSON approach does not give you everything-and-the-kitchen-sink. A lot of
people consider that a feature.

If you want to do schema validation on top of json messages, you're free to do
it when you receive them - the data format does not prevent you from that, it
merely does not advocate and standardize one-way-of-doing-it.

The fact the various _existing_ json schema solutions have not found a leader
amongst themselves speaks loudly to the fact that it's a useless feature for
most people, and the format is better off without it. Whatever the RFC would
come up with, people would find fault in it... so if most users don't care,
why force one solution over any other?

GP is foolish to think XML does not have benefits over JSON, but you're a lot
more foolish to think those benefits (the ones you advertise, anyway) should
be part of the language. You say "As JSON grows...", but that's exactly the
thing: it doesn't grow. It's a simple data format and needs no new feature.
Would trailing commas and comments be nice? They sure would. But we can live
without them in the format _itself_... let alone schema validation which can
be done externally.

~~~
personZ
_It 's a simple data format and needs no new feature._

XSLT was developed entirely independently of XML. XML Schemas were developed
entirely independently of XML.

XML itself is absurd simple. It is the epitome of simple. But you build an
ecosystem of tools and standards around it. And that is of course already
happening in JSON -- JSON Schemas, for instance, are now a thing.

~~~
scrollaway
> XML itself is absurd simple. It is the epitome of simple.

I can't possibly argue with you if you actually believe that. XML is not
simple. XML has CDATA, DOCTYPEs, comments, attributes, significant whitespace
and so much more which JSON does not have.

------
gioele
How many languages can tell you that byte X of output has been generated from
byte Y of input going though such and such steps?

When programming in XSLT it is great to fire up a debugger (let's say oXygen),
run your transformation, click on the wrong output and being able to go step-
by-step _backwards_.

How many languages designed before 1999 (yeah, XSLT is 15 years old) can claim
to be able to do so?

~~~
blablabla123
> How many languages can tell you that byte X of output has been generated
> from byte Y of input going though such and such steps?

Having written tranformations in Python that needed to carry that
information... How do you do that in XSLT? (And do you think it's worth
writing new code in XSLT?)

------
dexen
Also the venerable, tongue-in-cheek, "Not the comp.text.sgml FAQ" [1] by Joe
English.

Sample:

    
    
      Q.  I'm designing my first DTD.  Should I use elements or attributes to store data?
      A.  Of course.  What else would you use?
    

[1] [http://www.flightlab.com/~joe/sgml/faq-
not.txt](http://www.flightlab.com/~joe/sgml/faq-not.txt)

------
krab
The point with namespaces leads me to think that the main problem with XML is
that on the surface it looks very simple but in fact it's not. It is tempting
to take shortcuts to process the XML: for example parsing with regexes,
looking at the namespace prefix and not at its definition, producing XML
without proper escaping. There are also some gotchas like certain characters
being non-representable in XML.

I personally like XML and XSLT (2.0) but to be able to work efficiently you
need to spend some time learning which is not obvious on the first sight.

What about the alternatives?

JSON has a big advantage which is its unambiguous automapping to objects. This
benefit is not that apparent in languages like Java where you'd still declare
a class to represent either the XML or the JSON document. Moreover, there are
projects which essentially try to bring schema and namespaces to JSON. JSON-LD
is an example of a namespace without an explicit support in the underlying
format. There is even a command-line tool jq big part of which is an engine
similar to XPath.

S-expressions if used widely would probably go the same path as JSON -
recreating a lot of what is considered as bloat in XML.

Another mentioned alternative was a custom text format. I assume the author
meant just to design a format from scratch. I wrote that to use XML
efficiently, you need to put in some work. But compared to making a backwards
(and forwards?) compatible text format which correctly handles malformed and
malicious input requires much more effort.

I don't know anything about ndb.

------
ilitirit
XSLT does indeed have implementation issues, but it really is very powerful
once you know how to use it properly. And I don't get how it's a "failure".
It's one of the most widely used technlogies in the publishing industry.

Our company once had an application that processed the end-of-year high school
student results and then published them in various newspapers. The input files
were text files generated from the Education Department's database from
various regions. The process took around 10-15 minutes (lot's of rules had to
be run against the data). I replaced it with a Windows JScript script and
XSLT. It took 15 seconds to transform the data.

That said, I still use XSLT regularly but I'd be lying if I enjoyed working
with it. Using a decent IDE for development and debugging can help.

Someone did give me a nice tip for working with and learning XLST though -
"translate your transformation rules directly from simple English to the
template rules".

eg. "I need to insert the node <member> under <group>"

    
    
      <xsl:template match="group">
        <group>
          <member/>
          <xsl:apply-templates/>
        </group>
      </xsl:template>
    

"But if the group node exist, doesn't create, then create it"

    
    
      <xsl:template match="root[not(group)]">
        <root>
          <group>
            <member/>
          </group>
          <xsl:apply-templates/>
        </root>
      </xsl:template>

------
radicalbyte
The problem with XSLT, XML, SOAP, WS-* is that the community is driven by
vendors with deep pockets who use their power to kill interoperability.

Imagine LISP, but in the hands of Sauron or Palpatine. That's the XML group of
technology.

~~~
praptak
> Imagine LISP, but in the hands of Sauron or Palpatine.

Common Lisp?

------
paulsutter
JSON/Javascript is just easier to learn and work with than XML/XSLT. For
starters, you don't need to learn a special language that you'll never use for
anything else.

Just in case you /do/ need to use XML every day: the primary benefit of XSLT
is that it lets you avoid using XML libraries to munge some XML. Because the
XML libraries are so horrendous to use from any language.

~~~
qwerta
I am sorry but Javascript is not much better than XSLT. Horrible legacy
technology full of bugs nobody was bothered to fix.

~~~
Havvy
JavaScript isn't full of bugs nobody has bothered to fix. It's full of
specified behavior that cannot be fixed without breaking backwards
compatibility. That said, the issues are well known and actually bypassable.

Whether you should be using it for the problem XSLT tries to solve is another
question. Probably not, since there are other templating languages.

------
rwallace
The first part of the first quote is incorrect. The problem XML solved was
bloody hard, though most people nowadays have forgotten what it was. It was to
get the world's programmers to stop creating binary file formats, to put an
end to the situation where every time you went onto a site, the first thing
you had to do was reverse engineer binary files with a hex dump utility. XML,
to its very great credit, solved that problem.

Now if you want to start asking whether it solves the problem as well as
today's competing technologies like JSON, at that point I will step back and
hold my peace.

------
bibonix
XSLT is one of the most powerful and elegant technologies created in the last
15 years. Those who don't understand it and that's why can't use it, should
just do their home work and learn better

~~~
radicalbyte
The problem is that it's often misused. Using an XSLT that takes 0.5s to run
to transform some XML to HTML during web requests on a busy site? Idiotic.

Using it for async transformations - html to pdf, customer message format to
your message format. Fine.

~~~
crdoconnor
The problem is not that it is misused. The problem is that there is a small
subset of problems for which it works passably (like many other technologies)
and a large universe of problems for which it will cause you massive pain.

------
duncanawoods
I believe the fundamental pain of xslt was... that it was an FP language. When
teaching XSLT, the difference between those who said "its elegant" vs. those
who said "its pain" \- is whether the individual could grok FP.

Angle bracket overload, verbosity of end tags, library support, poor
whitespace handling, namespace pain were all obstacles too but it was FP that
made standard problems feel like math proofs and for developers to take days
to solve problems they could code in minutes in their usual OO/imperative
language.

When I see the pain FP causes in the real world I'm never quite sure whether
its nature or nurture. I currently believe its a bit of both but the nature
part will always hobble FP adoption - if you find algebraic proofs elegant,
you will like FP. If you are "normal" and proving a theorem fills you with
terror then you would prefer your programming language to resemble a a cookery
recipe.

I also believe all templating, especially for code-generation, requires three
brains - understanding the input data-structure, understanding the processing
of the template and understanding the behaviour of the output. Each keystroke
in your templating language has to be carried out with full understanding of
all three parts. Its too much for those if they still struggle with more
common two brain programming problems.

~~~
VMG
> I believe the fundamental pain of xslt was... that it was an FP language.

From the post I linked in my other comment

 _> 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._

~~~
sqrt17
That seems like the difference between object-based (early VB) and object-
oriented.

XSLT is referentially transparent (no setf for you) but withholds from you
most of the goodies that people take for granted in functional _or_ logic
programming.

You could see it was written by well-intentioned FP enthusiasts. IMO the best
alternative at the time when XSLT was developed would have been XMLPerl -
embedding an imperative language in something that deals with the XML-specific
parts appropriately. But Perl was never enterprisey enough, and XmlPerl died a
painless death.

------
kabdib
I once worked on an embedded system with not a lot of RAM or code space, and
we were ripping features out to put new stuff in and rewriting things to make
new things fit (not a bad practice, re-writing, btw). I wrote some tools to do
global optimization at the assembly language level and got back 40K because
our compiler was one of those $5000 / seat pieces of crap, and we didn't have
a debugger, so object-to-source-line mapping, who needs it?

Anyway, one of the PMs on the project insisted that this choice little
hunk'O'hell communicate with the outside world -- at about 2K bits / sec on a
good day -- using XML. Because it was standard. Because XML added to anything
makes it better, no matter what it is. Because, well, nobody ever saw that
traffic except other computers, but XML!

I wanted to kill, kill, kill, but instead I wrote an XML parser (kind of) that
fit into about 1K of code. "Don't use entities or CDATA or namespaces," I
said, and went away to a better place. I think the PM was happy. That group
got sold to a company famous for its 60s-era radios and crappy teevees, and I
assume everyone is happy there, because I have not heard a word from them, and
XML!

------
chinpokomon
I've seen XSLT done well, and I've seen the mess it can be when written by
someone with only a passing knowledge. As a consultant I usually have dealt
with the latter, and that usually goes hand in hand with a poorly designed XML
schema.

One space that XSLT can demonstrate its strength is when transforming some
horribly serialized interoperability data structure. If the system from which
you are receiving data, produces terse XML, you aren't going to solve anything
by rewriting the upstream system to produce equally lousy JSON. If you don't
have the ability to fix the upstream service to produce better structured
data, XSLT and XPath are wonderful tools to morph it into something more
manageable. That transformation process is better written with XSLTs than it
is in trying to do the same thing by slurping the data directly into some
business object and trying then to work with a bad model. Don't go down the
path of "garbage out, garbage in."

If you have access to both sides of the process, it might be worth rewriting
the upstream system, but when working with a legacy system XSLT might be the
best glue technology in your arsenal.

------
ohyesyodo
Okay, so what am I supposed to use if I want to transform a XML file from one
format to another because two different systems needs XML for input /output
and they have different fixed formats?

~~~
crdoconnor
I would use a language that has a decent XML parser (e.g. python + lxml) for
input and a decent templating language (e.g. jinja2) for output.

Assuming it was a simple transformation, the python parsing code could be
under 10 lines. Most of what you wrote would be templating. It would be 98%
declarative.

If it got complicated though (e.g. you're doing some aggregation or
something), the python bit would grow but it probably never end up looking
that horrendous, unlike XSLT.

The same pattern could be applied to many other language ecosystems. You just
need to make sure you get the best XML parsing library and the best templating
language.

~~~
ilitirit
You could do the exact same thing using XSLT. eg.

    
    
        var result = new XSLTProcessor().importStylesheet(xsl).transform(....);
    
    

It's a bit of a pointless example because it really depends on the
transformations you need. I'm sure in some cases XSLT would be better for the
job, and in other cases another language. Most of the time it would generally
just depend on your environment, available tools and skillset.

~~~
crdoconnor
>I'm sure in some cases XSLT would be better for the job

In some (simple transformation) cases XSLT would be no worse, but mostly it
would be worse. I can't see it being clearer or easier to maintain under any
circumstances.

Once your code evolves toward doing anything mildly complicated you'll wish
you never made your transformation in xslt.

------
snarfy
I like this one:

>“XML combines the efficiency of text files with the readability of binary
files”

One dirty thing about XML is that it appears human readable, but it is not
human writable. You'll see something in the XML that you think you can change,
but now it doesn't validate anymore after you change it using a text editor.
You need an XML editor that understands XML validation to make edits. If I
cannot use a basic text editor, it's not basic text. If it's not basic text,
it's no better than any other binary protocol, albeit a very inefficient one.

~~~
Mikhail_Edoshin
How do you manage to change C or Python source code? Omit a ";" in C or ":" in
Python and it will refuse to compile.

~~~
pm24601
I normally don't do +1 on a one-line answer but this was the perfect rebuttal.

I wonder how s/he does handle that pesky ';'

------
hokkos
What article are we supposed to look at ? It is witty quotes and links, there
in no substance is this article, just bashing. Is it supposed to be an answer
to this article that had a lot of discussion on proggit ?
[http://www.reddit.com/r/programming/comments/2o5nvy/why_i_li...](http://www.reddit.com/r/programming/comments/2o5nvy/why_i_like_xslt/)

~~~
mhd
I wasn't surprised, given the domain. Plan 9 fanboys tend to have a very
simplistic view of the world and think that "KISS", "do one thing well" and
"just pipe stuff" is the universal solution to all problems.

If the alternative look like a (t/n)roff file, I'd gladly take XML, though.

------
brokentone
Reminds me of the person (people, team, etc) who decided it was a good idea to
code websites in XML + XSLT. Because XHTML is just not good enough. The most
prominent of these (I'm shocked it's still this way) is
[http://www.skechers.com/](http://www.skechers.com/)

~~~
lsaferite
Why are you shocked? Investing in a software stack for a website is non-
trivial. If it's working for them then it's throwing money away to change it
right now.

------
pm24601
The problem with most tools is that they go through the "bright and shiny"
stage:

    
    
      "New tool - cool! Lets use it on EVERY problem."
    

And are thus misused.

XSLT exists for inter-organizational data transfer and transformation. Don't
use it for any other situation.

XML is a good (not perfect) persistent data storage mechanism where you need
the data to outlast the program that created it.

I go into more explanation here: [http://sworddance.com/blog/2014/12/06/xml-
is-not-bad-just-mi...](http://sworddance.com/blog/2014/12/06/xml-is-not-bad-
just-misused/)

Lets not blame a tool that was misused.

------
considerjoost
If you ever find yourself somewhere you have to work with XML data and the
people there use things like XSLT (and suicide is not an option) you should
consider using Joost. Joost implements the lesser known STX language. It's a
far cry from Haskell or other better tools but nonetheless more useful and
practical than XSLT for tasks like cleaning and extracting interesting things
from blobs of XML. It's available here:
[http://joost.sourceforge.net](http://joost.sourceforge.net)

------
mqsiuser
Software hackers will come up with a single right solution. This solution is
cemented in theory. Transforming one (message) tree into another _must_ be
done in the following way:
[http://www.usethetree.com](http://www.usethetree.com)

Don't just downvote me. Challenge me!

Edit: Maybe downvote & challenge me :-) ?

------
cenazoic
Anyone tried the "XSLT-powered open source content management system",
[http://www.getsymphony.com/](http://www.getsymphony.com/)?

~~~
ogig
I've made several small sites with it. It used some great ideas like the data
model been totally flexible while easy to use and xml + xslt as server side
templating was nice to use. The in-browser developer tools were good too.

Unfortunately there were also a bunch of bad points that never got fixed.
Breaking changes for pluggins exhausted the small contributors community. I
think the project is basically dead at this point and I've moved to another
cms for small sites. (Keystone.js)

All in all, if i were to rewrite symphonycms now, i would drop xslt in favour
of jade or something less anoying to writte in.

EDIT: I've been browsing symphonycms repo after writting this and it's untrue
to say the project is dead since Brendo is still actively commiting.

------
jules
The syntax of XSLT is obviously godawful, but the architecture was sound.

------
icantthinkofone
I think I should collect a bunch of quotes espousing the virtues of XML and
XSLT and put them on a web site so people can link to them.

------
lafar6502
xml is technically a superset of JSON, just can't imagine any clear advantage
of JSON vs XML - it's the same league, just some minor syntactic differences.
And what is the end of the story for JSON, is just a beginning in XML: the
concept of namespaces is powerful and totally foreign to JSON. Then XML Schema
- another job well done and poorly mimicked in some JSON libraries. XSLT just
builds on these concepts and is not a general purpose tool - don't see a
reason to have strong opinion about something so narrowly specialized.

------
Mikhail_Edoshin
I really don't understand how programmers can hate XSLT (and XML for that
matter). It's a marvelous piece of technology, truly. Maybe the whole stack is
so ahead of its time that nobody gets it?

------
miohtama
XSLT is 15 years old technology. If it is painful or not should be obvious
today even before starting a project.

------
tete
cat-v is actually pretty nice. A lot of their stuff looks a bit like "Oh my
god, why" and "That person just doesn't have a clue". I thought the same with
so many technologies that I got into. I always thought KISS was nice and I
always felt like abstraction is a good way to reach that KISS.

Turns out it is not. Things can fail, really badly even and they do fail,
really often even, even when there are companies with big pockets standing
behind it and then good luck debugging the mess. This is true even for really
proven technologies, but might be less obvious on those.

At some point when you are good at some technology, even if it's really
popular, mainstream, be it some big SQL database (yes, all of PG, SQLite and
MySQL even though I love some of those), C, C++, Java, C# or
Python/Ruby/Perl/Node.js you will constantly end up with the implementation of
the underlying technology.

I am not saying XSLT or any of the above don't have their use cases, but
actually that a lot of them are over-engineered. Using most of these
technologies I know there are issues, send bug reports and patches and hey,
things get fixed really quickly. That's all good and you never can fully avoid
these things, but the more simpler you get the less there is that end up
biting you and causing you to start out with lets say you having your SASS to
CSS compiler having an issue, digging deeper through every library finding a
GCC bug or whatever. Such things happen.. more often than one would think. So
based on developer pay and the issues it causes (often being a blocker for a
whole team) that's actually a really big problem.

~~~
danieldk
_but the more simpler you get the less there is that end up biting you_

And increasing the probability that you invent the wheel, badly. I have been
using libxml and libxslt for years and as far as I remember I never
encountered a bug. Both projects have been developed for years and is used by
a gazillion other projects.

It is many times more likely that you will be bitten by a bug in your own
custom configuration file parser than e.g. in libxml2.

I am not arguing for or against XML, but code reuse. Simplicity also means not
reinventing the wheel and keeping your own projects simple by leveraging
existing, good, libraries.

