
Ask HN: Is there a future in XSLT? - rob
I've been looking for a content management system and came across Symphony (http://symphony-cms.com/). After playing around with it, I like how it works — but it uses XSLT for its template system.<p>I don't know XSLT. I've read a lot of negative opinions on it browsing reddit and HN, so I'm not sure if it's worth learning or not just to use Symphony. I also don't see it mentioned that much on the web, and there's not too many recent books on it on Amazon. I've been using HTML 5 recently as well, and I have read about some difficulties using HTML 5 and XSLT together.<p>Just thought I'd get HN's opinion on what they think of XSLT and its future.
======
roel_v
I think it's pretty much a dead technology now, except for legacy uses like in
big XML-heavy Java frameworks that were early adopters. I've tried using it
for document transformation purposes several times but never found a use where
it wasn't easier to just write a DOM-manipulating script. As a templating
system I don't see any advantages either - conceptually it's nice to force the
separation of programming logic and templating functionality, but then again,
you soon need similar constructs (if, loops, includes, ...) anyway and then
you have to switch to xslt extension libraries... When it comes to templating,
I still much prefer showing programmer constraint is a better way to go than
technical barriers. That tradeoff may be different in a context where you have
dozens of programmers/designers/content producers work on a site. But for a
site of that size performance would presumably exclude XSLT.

In general, I get the impression that the 'XML everywhere' fad has passed and
that technologies like XSLT, xsl:fo and the myriad of xml replacements for
DTD's have passed their peak a few years ago.

~~~
yesimahuman
Yes, it is definitely being used in some very large and prominent
applications, but in my experience the developers and management are aware of
the deficiencies and want to move past it (but this takes a long time). I
don't see a need either to start learning it now, unless you happen to go work
for one of these companies that use it extensively.

Ultimately it always seemed to me like it was a tool to deal with the non-
uniform hacky XML data the company had literally everywhere. Perhaps that's
the problem that needs to be fixed.

------
grayrest
XSLT was created to allow for document tree translation in an implementation
independent manner. The main problem I have with this concept is that document
translation is that 99% of the time you're doing it, it's to get the document
to the format your app needs or from the format your app needs. In other
words, the vast majority of translations depend on the implementation, so
what's the point of an implementation independent translation language?

So on its own as a templating language, XSLT 1.0 had problems of varying size.
The biggest by far was that the 1.0 spec had the absolute worst string
handling of any language I've ever come across. It's erlang bad with the
syntactic elegance of being an XML language. This is somewhat corrected in
more recent versions but I think this is the primary reason the language has
failed to gain adoption. If you're doing whole node manipulation, XSLT is
adequate. It's not elegant, but it's flexible and I generally don't have
problems getting the results I want in short order.

I do like a number of ideas present in XSLT, particularly the concept of
templating documents as trees (guarantees well formed output) and
transformation by pattern matching. Those both carry over into my preferred
templating language, Python's Genshi, which some people like and some hate. To
me it provides a good balance between purity and practicality.

As to your specific questions, I did one site in pure XSLT back in 2003-2004
and vowed I'd never do it again. I have a guy at work who really likes
Symphony and produces good quality stuff with it. If I had to do PHP it'd
actually be one of my top choices (I don't like PHP either...). I've never
regretted learning xpath, since it seems to pop up regularly in unexpected
places and isn't THAT complex. The complexity in xpath comes from many
implementations not fully implementing the spec. HTML 5 has an XML encoding,
so there's no reason that XSLT would work worse with HTML 5 than it does with
XHTML.

XSLT will never be the one true path for templating, but its presence as a
standard will always attract people who appreciate that sort of thing (I'm not
one of those people) so it's not really a dead end either.

------
xsltuser2010
Knowing XSLT for a while --

I wouldn't use it for a web framework, it just seems to be the wrong place. I
use xslt for simple document transformation. Say you often have to deal with
ridiculously complicated xml files and want to adapt them quickly and in batch
to something, then using xslt is a nice way to go.

You should know functional programming to get anything more done than just
throwing out some nodes, though. And the hard part about xslt ist actually
xpath, which I still have problems with even after years to get the syntax
right..

(I'm not a daily user, but it's my usual tool for that matter)

~~~
matwood
I agree to avoid it with a web framework. It's just not worth the hassle in
that sort of application. Where I still use it though is for reporting
systems. Have your datasource output XML and then have an xsl for the web
report and a xsl-fo for a printable PDF report.

At the time I wrote the reporting system it was to replace Crystal which I
found to be much more of a pita and more expensive.

------
kj12345
If you do use XSLT make sure to use 2.0 if at all possible. It has some key
features like extra built in functions that make it a lot more palatable.

Personally I think XSLT is an interesting language from a theory perspective,
and it taught me some interesting things about rule-based programming. However
there are too many serious limitations in it in terms of everyday practical
use. In addition to the verbosity problems others have mentioned, here's a
good list of things XSLT can't do:

<http://www.dpawson.co.uk/xsl/sect2/nono.html>

------
flatline
Xslt is kind of fun to write IMO - not so much fun to read or maintain. It is
very nice for simple transforms and document generation but I've worked on a
template system that used it extensively and it was a nightmare to make
updates. I'd stay away from heavy use of it if at all possible.

~~~
jamesbritt
It's a good excuse to play with functional programming, in a kind of brain-
teaser sort of way, but it ends up feeling like a a lot of work to accomplish
most of the things you want to do.

------
pook
Cobol is still being written.

There is a future, but the real question is: is it a future worth going into?

I wonder if there's any attempt to fork Symphony onto a different templating
system.

------
InclinedPlane
The only response I can come up with is: "god, I hope not!"

------
Tichy
Avoid it like the plague, would be my advice.

------
xchaotic
Hi guys. I use XSL everyday and what you need to understand it's not a generic
programming langague like Python, it's a DSL meant for transforming from one
form of XML to another. If you're doing x = x +2 in XSL you're doing it wrong
and that's why it's so awkward. XSL is very strong in that one domain only -
declaratively transforming XML. It's actually much easier to maintain rules
than any other language I tried for this particular purpose. I just hope
people won't try to use it too much - it has it's own niche and because XML is
everywhere now it's a fairly big niche, but it's best used sparingly and in
combination with other technologies.

------
aristus
You may or may not know of a famous post declaring the death of FreeBSD, which
was abstracted to cover several other technologies. [If not, google for
"netcraft confirms it".]

I personally would not bother. I played with XSLT and its predecessor called
DSSSL or something like that, back in the late 90's. It hasn't taken over the
world yet, and I don't expect it to surprise us. There are many other ways to
manipulate a DOM, eg Javascript, that are much more sophisticated and widely
supported.

If you want to get a particular job that requires deep expertise in XSLT,
well, that's your decision. But I would not peg it as a generally-useful
skill.

------
Amanjeev
I agree with most of the folks here. XSLT in framework is just not the right
place.

1\. It is bulky and comes with a lot of baggage. 2\. Writing even a small
statement like int x=2 in xslt is an arduous task of <xsl:variable
select="blah blah"/> (this is the shortest way, it gets even longer if you
need to do more complex stuff. 3\. It is not advanced enough like 'real'
programming languages.

The only thing I would use XSLT for is document transformation. I totally
agree with xsltuser2010 (<http://news.ycombinator.com/item?id=1330691>)

------
lsc
so most people hate XSLT. Personally, I find it interesting because it's a
language independent templating system, and as far as I can tell, it's more
popular than any other one templating system. There's a fair bit of XSLT
available out there for your use.

The problem I have with most templating systems is that they are extremely
language specific. I want the design guy to be able to style any page, be it
generated by perl, php, C, etc...

------
arethuza
Having used XSLT quite a bit I now avoid it - for generating HTML simpler
templating tools are much easier to use (I using StringTemplate but there are
plenty others) and for manipulating XML I actual find I prefer normal code in
Java/C#/Javascript.

------
cwisecarver
I use it at work for most of our web templating. It beats dealing with
microsoft webforms but that's the nicest thing I can say about it.

It's a very fast, computer time not developer time, way to make HTML if your
datasource is XML.

------
drawkbox
No.

Ok to elaborate, there are too many walls you hit in using XSLT. You'd be
better off with a templating layer with a faster language much like tenjin,
mako, jinja etc in the python world but every platform has them.

------
percept
Based on job ads I read XSLT still has a future--in the enterprise. :|

