Ask HN: Is there a future in XSLT? | Hacker News Reader

Ask HN: Is there a future in XSLT?

22 pointsrob21 comments

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.

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.

Just thought I'd get HN's opinion on what they think of XSLT and its future.

View on HN

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.

I totally agree. In a previous job, we had a system that used XSLT to generate the public website. I never really cared for it. The language seemed very verbose and you can do the same thing in other languages more simply. I think xsl:fo still has some uses when generating dynamic pdfs. Other than that, I would stay away from it if you could.

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.

Right, not worth learning it now. BTW Blizzard uses in-browser XSLT on most of their sites - http://extremelyxslt.blogspot.com/2008/07/world-of-xslt-craf...

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.

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)

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.

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

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.

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.

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.

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

Avoid it like the plague, would be my advice.

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.

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.

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)

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

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.

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.

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.

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

Reply on news.ycombinator.com