Why is XSLT so rarely used on the web? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.