24

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?

Boann
  • 109
  • 4
George Sovetov
  • 383
  • 2
  • 9

4 Answers4

53

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 1
    Very informative answer (+1). – Giorgio Oct 21 '18 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 (`<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).</par> – SJuan76 Oct 21 '18 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 '18 at 06:09
  • 1
    @JacquesB I used that couple for that page: http://www.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! – programaths Jan 12 '20 at 09: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. – Mikko Rantalainen Jun 18 '21 at 07:23
19

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.

Michael Kay
  • 3,360
  • 1
  • 15
  • 13
  • 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 '20 at 00: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. – Michael Kay Oct 20 '20 at 08:32
  • 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 '20 at 11:03
  • 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. – Michael Kay Oct 21 '20 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 '20 at 13:01
  • I did say it was a love-it-or-hate-it language. I can see which group you're in! – Michael Kay Oct 22 '20 at 15:28
  • @user151496 To me XSLT is much like SQL - it keeps being powerful enough. – Thorbjørn Ravn Andersen May 09 '21 at 20:36
  • I love it so much that I googled "is XSLT still used", in hopes that the answer was "yes"! I did some work in it a _very_ long time ago now. (I later did work in a Perl sub-language called XSH which was extremely cool, btw. In a way, it was more.. "interactive"). Always a part of me that wishes I could still get some contract work doing that! — I think it's a little bit like calculus or something — once you get it, you can't un-get it but it's hard to get.. – Chris Burbridge Jun 19 '22 at 16:34
6

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.

Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • XML Syntax indeed may look verbose. But, what are some other languages that are supported everywhere? – George Sovetov Oct 21 '18 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 '18 at 13:08
  • 5
    @GeorgeSoverov why is it important to be supported everywhere? It only needs to be supported on your server. – Esben Skov Pedersen Oct 21 '18 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 '18 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 '18 at 16:34
  • 1
    Well, you certainly demonstrated that it's a question that attracts opinion-based answers... – Michael Kay Oct 21 '18 at 20:51
  • @GeorgeSovetov who is doing templating in js (for service calls)? A simple XML serializer should do the job. – Esben Skov Pedersen Oct 23 '18 at 14:49
  • I'm not sure what are "service calls". To show a page in the browser you have to make a HTML somehow. The "default" way to do this on the client side is to get JSON and make chunks of HTML code. One can do that by manipulating with jQuery or use something line Angular. Both of them are implemented in JS. – George Sovetov Oct 23 '18 at 19:33
0

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.

Joshua
  • 1,438
  • 11
  • 11