Templates: XSLT vs jQuery

I need a templating mechanism for html-pages bundled with my app. At first开发者_运维问答 I looked at all the javascript templating solutions (like jQuery templates), but since my input data is XML, I suddenly remembered XSLT again. I came across tens of libaries, but none seemed to make use of XSLT, so I completely forgot about its existence, and how useful it is for creating templates.

So, is XSLT slowly deprecated and phased out by javascript alternatives? I read somewhere XSLT was too complicated for most users to work with, but is that its only downside or are there more cons?

Update: I can think of only one disadvantage myself: with XSLT the complete page has to be parsed/rendered before displaying anything to the user, and with the javascript the page is already visible and the missing elements are filled afterwards.

XSLT is a modern XML transformation and functional programming language. The upcoming version 3.0 natively supports (together with XPath 3.0) higher-order functions, among other new features.

XSLT isn't "old" (few people know XSLT 2.0 or are aware that XSLT 3.0 is being worked on by the W3C XSLT WG).

XSLT in the browser had a recent big push forward by Saxon CE -- a trimmed down XSLT 2.0 processor that is compiled from Java to Javascript and is available client-side on the five major browsers. @Michael Kay even demoed XSLT 2.0 running client side on his iPhone...

XSLT is a good solution for templating. The language and syntax are a bit unusual -- "choose/when" instead of "case/switch" is a glaring example -- but it does its job well.

XSLT's main advantage is that you don't need JavaScript to use it; build it right and every major browser will render it as HTML whether JS is enabled or not. It may be easier on the processor than JavaScript solutions, although I don't know anyone who's tested this. It's also the obvious choice if you're already dealing with XML data, as you are.

The downside is that it's a (relatively) old technology which has been largely abandoned, and while browsers still support it, they haven't moved forward with it. Firefox has an issue with HTML escaping that they have no intention of fixing, and Chrome has a pretty major problem with @includes. IE is apparently up-to-date, but that of course only applies to the latest version.

The upshot is that if you want to use XSLT, you have to test it in all your major browsers and work around the bugs, despite the fact that the technology has been around since at least 2006. It is by no means deprecated, it's just not very popular because it's not as compact or easy to read as, say, JSON + jQuery templates.

Rendering XSLT in the browser has some strange browser-specific quirks. I would rather use jQuery templates if I needed to render data on the client side.

On the server side, XSLT is a great tool with support for many programming languages (at least for XSLT 1.0, for XSLT 2.0 you can only choose between Java and .NET). So maybe you can have some kind of middleware that gets the client-side request, passes it on to the web service or whatever is generating the XML, renders it as HTML with an XSLT style sheet and passes the HTML result to the browser. If your specific scenario allows caching in the middleware layer, your application will also be faster since the client does not have to process jQuery or XSLT templates.

Here is the example to load XML and XSL and perform transformation in Javascript. http://www.w3schools.com/xsl/xsl_client.asp

Sometimes it is not possible to import XSLT in XML document, for example getting XML from third party and using your XSLT transform to HTML and render in browser.