XSLT is a mature, widely accepted standard.

It can be used in browsers (even in old IE) and on the server side (nginx has an XSLT module, which can be used from programming languages, of course). Its implementations are compiled and, therefore, should be much faster than Python or JS. The JS implementation Saxon JS can be used, at least, as a fallback. Jinja, Angular, Ruby's Slim, ASP and PHP templating are not even close.

An XSL template can be easily validated in an IDE. How many IDEs can help with Jinja or Angular?

It looks like it's a perfect idea to decompose UI and data with XSLT.

Admittedly, implementations can give different results in some corner cases, but it's a problem only with templating on the client side. And it's same with HTML, CSS and everything else that is done on the client side.

So, why not XSLT?

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, Eric King, TheCatWhisperer, Thomas Owens Oct 21 at 19:18

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    JSON is easier than XML. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again. See: stackoverflow.com/questions/4862310/json-and-xml-comparison – Dan Wilson Oct 21 at 13:29
  • 6
    Have you ever tried doing something nontrivial with it? – PlasmaHH Oct 21 at 16:45
  • 9
    Is 'because it is agony to use' a valid answer..? – thisextendsthat Oct 21 at 16:53
  • 2
    @thisextendsthat: No, because JavaScript and CSS also used to be agony to use, but still became widely used. – JacquesB Oct 21 at 17:55
  • 4
    @JacquesB JS and CSS are still agony to use. – Andy Oct 21 at 22:46

XSLT does not really have a useful role in the modern interactive web. The purpose of XSLT is to transform from one XML language into another - but you actually never need to do that in the first place. How powerful, fast and well supported a technology is is irrelevant if you don't have the problem which the technology is designed to solve.

There are several reasons why the use case for XSLT has gone away:

  • HTML has won. XSLT was supposed to be useful for transforming "rich text" content in some semantic markup format into HTML. But HTML is in itself a perfectly fine format, so why not just use that for the content in the first place and skip the transformation?
  • CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on. But you don't really need presentational HTML these days, you can use semantic HTML and CSS can perform the necessary styling and layout.
  • XML has not become the ubiquitous format for data. When fetching SQL data from a database it is much simpler to just directly merge it into a template, rather than first transform it into XML and then transform it via XSLT. And JSON has all but replaced XML for structured data on the client side.
  • XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page.
  • Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.

XSLT grew out of publishing where you could have a one-way process from one structured source format to multiple publishing format like print, PDF and static web pages. Most web sites does not fit this use case.

  • Very informative answer (+1). – Giorgio Oct 21 at 17:56
  • I do not know if my experience is the same than other users', but one of the "selling points" of XSLT as explained to me was reduced bandwidth: if you have a large, regular page you send a minimal XML (<chapter><title><par>...) and XSLT would "expand" it with the div, table, tr as needed, with the addition that it could be cached. So (again, I do not know how widespread was this "advantage" explained) the improved bandwidth would have also hurt it (and the fact that most HTML pages are fairly small). – SJuan76 Oct 21 at 18:54
  • @SJuan76: That is a take on the idea to transform semantic markup into verbose presentational HTML that uses tables for layout. Luckily it is no longer necessary to use tables for layout so that use case is moot. – JacquesB Oct 22 at 6:09

Depends what you mean by "in Web".

XSLT is very widely used. As far as we can judge from metrics like the number of StackOverflow questions, it is in the top 30 programming languages, which probably makes it the top data-model-specific programming language after SQL.

But XSLT isn't widely used client-side, that is, in the browser. It's usually used either server-side to deliver content on demand in response to HTTP requests, or it's used in batch mode as part of a publishing workflow. It's also used, of course, in many applications that have very little to do with the web, e.g. in print publishing.

There are a number of reasons XSLT isn't extensively used in the browser. The main reason is that good conformant XSLT support was very slow coming from the browser vendors; no-one wanted to use it until it was available on every browser, and by the time it was available on every browser, the things people wanted to do in the browser had moved on (remember "Web 2.0"?) and the XSLT implementations in the browser didn't help you build interactive applications or fetch data using AJAX.

Saxonica (disclaimer, this is my product) has attempted to plug these gaps with Saxon-JS, but the product is a latecomer to the party, and client-side web development is very fashion-driven, so it's not enough just to have a product that ticks all the technical boxes. Part of being fashion driven is that most data-oriented sites (as distinct from document-oriented) have moved towards JSON rather than XML, largely because JSON is much easier to manipulate from Javascript.

The other issue is that XSLT is a love-it-or-hate-it language. Its declarative, rule-based, functionally-oriented paradigm appeals to many because of its high-level nature, but can be off-putting to those whose only experience of programming is to write imperative code that tells the computer exactly what to do and in what order.

I am flip-flopping back and forth between answering this question and closing it as primarily-opinion-based. So, here's my flip:

In short, because XML makes a crappy programming language. Something with the semantics of XSLT but much better syntax would be a whole different matter, I think. There are some really cool Lisp-based XML-transformation languages, for example.

XSLT can't decide whether it wants to be a tree-rewriting language, a functional language, or a procedural language. It has features of all of those, but it isn't really good at any of them. For any of the three aspects, there are better languages out there.

  • XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere? – George Sovetov Oct 21 at 12:36
  • XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic. – RubberDuck Oct 21 at 13:08
  • 4
    @GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server. – Esben Skov Pedersen Oct 21 at 13:14
  • @EsbenSkovPedersen to work with services that speak HTTP/XML from browser and, at the same time, avoid templating in JS. – George Sovetov Oct 21 at 14:16
  • 1
    I think the ugliness of a language is irrelevant if it serves a relevant use case. Just witness the success of JavaScript. The problem with XSLT is the use case just isn't there. – JacquesB Oct 21 at 16:34

Because XML itself looks like obsolete backwards-compatability junk for 99.9% of cases.

The only use case for which XML doesn't have immediately superior replacements is things like docx or odf, and it's possible that SGML would have been better*. That is, we have incredibly rich document structure with all kinds of things nested inside of each other with large transforms being applied so it can appear correct on the screen and the printer.

Almost all the time, XML is used for passing structured data around, and it appears that XSLT is designed to transform structured document data into document data. That use case is dying out. JSON is directly superior to XML for structured data.** Both markdown and YAML are superior at lightly formatted data. XML's initial leg-up was the built-in parsers in Java and Javacript. JSON broke that barrier by leveraging a built-in parser for the cases where the JSON source is trusted (which was most of them when it was young).

And the world is changed. The built-in library advantage is a trivial advantage now. XHTML was rejected outright and its replacement didn't inherit from it but from its predecessor.

XML is now used for talking directly to the guy who wants to receive it, and it's generated in whole cloth in the format wanted, or conversely it's read in and parsed to object model directly from the form its sent in. Since it's no longer a storage format or a universal interchange format, transforming it from schema to schema is no longer required.

*They taught in college that SGML was never implemented. They lied.

**I've heard the complaints about bad number formats in JSON. On the other hand XML has no number format so just stuffing all the data types in string still wins against XML.

Not the answer you're looking for? Browse other questions tagged or ask your own question.