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?

  • 5
    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, 2018 at 13:29
  • 6
    Have you ever tried doing something nontrivial with it?
    – PlasmaHH
    Oct 21, 2018 at 16:45
  • 10
    Is 'because it is agony to use' a valid answer..? Oct 21, 2018 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, 2018 at 17:55
  • 4
    @JacquesB JS and CSS are still agony to use.
    – Andy
    Oct 21, 2018 at 22:46

4 Answers 4


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.

  • 1
    Very informative answer (+1).
    – Giorgio
    Oct 21, 2018 at 17:56
  • 2
    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, 2018 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, 2018 at 6:09
  • 1
    @JacquesB I used that couple for that page: programaths.be/job/job.xml and it made perfect. The XML is used to display the page AND check for the answers to the generated questionnair. It's not about formatting in tables, but the XML offers me a good abstraction. Of course, I don't care about people cheating. But it shows that even in modern times, it can ne very useful! Jan 12, 2020 at 9:53
  • 1
    Good answer! I'd like to add that one big problem with XSLT was that it disabled incremental rendering of the document meaning that nothing can be rendered before the main document and the XSLT stylesheet have been downloaded and processed and only then the user agent (browser) can figure out if it needs to download external CSS stylesheets or fonts before being ready to render the main document. If you think that FOUC or FOUT is bad, it's nothing compared to throwing XSLT to the mess. Jun 18, 2021 at 7:23

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.

  • 1
    i actually think that most of the metrics like the number of StackOverflow questions is mainly students forced to use it in order to pass a course
    – user151496
    Oct 20, 2020 at 0:28
  • 1
    Unless you have evidence, your conjectures are baseless. I know thousands of real XSLT developers, but I have no idea whether the true number is a hundred thousand or a million. Neither do you. While there are certainly plenty of questions on SO from people who are complete novices both in XSLT and in programming generally, there are also plenty of questions addressing problems that are way harder than any instructor would set in a training course. Oct 20, 2020 at 8:32
  • 1
    but this statement is as baseless as the assumption that the actual amount of real xslt developers is measured by amount of the stackoverflow questions regarding the language :S
    – user151496
    Oct 21, 2020 at 11:03
  • 1
    In the absence of any information to the contrary, it's perfectly reasonable to assume that a language that is in the top 30 on StackOverflow is also likely to be in the top 30 on other metrics. Oct 21, 2020 at 16:12
  • 1
    well, that's why i'm telling an insight that there's a lot of students who are forced to use this combersome language for it's semantics value
    – user151496
    Oct 22, 2020 at 13:01

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? Oct 21, 2018 at 12:36
  • 1
    XSLT is an excellent functional language IMO. Where it falls down is in the way it mixes view w/ transformation logic.
    – RubberDuck
    Oct 21, 2018 at 13:08
  • 5
    @GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server. Oct 21, 2018 at 13:14
  • 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, 2018 at 16:34
  • 1
    Well, you certainly demonstrated that it's a question that attracts opinion-based answers... Oct 21, 2018 at 20:51

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.