Why has XSLT never seen the popularity of many oth

Question

The use of XSLT (XML Stylesheet Language Transform) has never seen the same popularity of many of the other languages that came out during the internet boom. While it is in use, and in some cases by large successful companies (i.e. Blizzard Entertainment), it has never seemed to reach mainstream. Why do you think this is?

Answer 1

I think it boils down to XML syntax is arguably good for describing data, but it's not a great syntax for what's essentially a programming language (XSLT).

Answer 2

I found it great for 'composite web service architecture'.Sometimes number of webservices work together to have the final output.When those webservices need to communicate among them via XML then XSLT can transform the xml message from one form to another.

Answer 3

Because most XSLT implementations have a high memory footprint (I suppose that's caused by the design of the language), because people tended to abuse XSLT for all kinds of things that it was not particularly well-suited for and the purely-declarative nature of XSL which makes certain types of transformations quite difficult.

Answer 4

In my opinion, one of the most annoying things in standard XSLT (I'm talking about XSLT 1.0 because that's the only version I have used) is that it lacked support of string transformations and some basic date-time functions manipulations.

One thing I could never understand is why a function such as translate() was designed and implemented into xpath wheras other more useful functions such as replace, to_lower, to_upper, or - let's be crazy - regular expressions were not.

Some of these issues were adressed I guess with eXSLT (extended xslt ?) for parsers other than Microsoft's MSXML. I say I guess because I actually never used it as it was declared incompatible with MSXML.

I don't understand why XSLT 1.0 was designed with this principle that 'text' manipulation was not be in the scope of the language when it's obvious that whenever you are converting files you can't avoid those string conversion issues (e.g. : transform an unregularly padded date given in french format to american format, 31/1/2008 to 2008-01-31) huh...

These text manipulation issues were generally very basic and easily adressed in MSXML by allowing XSL to be extended with JScript functions : you could call a JScript function to perform some processing just as you would call any XSL template, but I always found that solution inelegant and ended up creating my own XSL template libraries. First because the JScript way broke your XSL portability, and then because it forced you to mix your programming logic : some bits in pure XPath/XSLT expression and other bits in DOM/object notation with JScript.

Not having updatable variables is another limitation that is very confusing for newcomers, some people just don't overcome this and keep struggling with that. In some simple cases you can have workarounds with a mix of paremetrized templates and recursive calls (for example to implement an increasing or decrasing counter) but let's face it, recursion is not that natural.

I think I heard all those limitations were adressed in the XSLT 2.0 specification, sadly MS decided not to implement it and promote XQuery instead. That's sad, why not implement both of them? I think that XSLT would still have a good chance of becoming as popular as CSS became for HTML. When you think about it, the most difficult part in learning XSLT is XPath, the rest is not as difficult as understanding the cascading behaviour in CSS, and CSS has become so popular...

So, in my opinon, it's the lack of all those little things mentioned here and the time it took to adress them in XSLT 2.0 (with not even MS supporting it anyway) that has lead to this situation of impopularity. How I wish MS decided to implement it after all...

Answer 5

As previously stated XSLT (like “the good parts” of JavaScript) is a functional programming language. Most traditional programmers hate this statelessness. Also too many traditional programmers hate angle brackets.

But, most importantly, correct use of XSLT solves both the declarative-GUI-generation and the data-binding problem for the Web server in a platform agnostic way. Vendors like Microsoft are not motivated to celebrate this “inconvenient” power.

However, I will argue that Microsoft has the finest XSLT support for the IDE (Visual Studio) in the world.

Answer 6

One problem is that XSLT looks complicated. Any developer should be able to pick up the language constructs as there are analogs in most other languages. The problem is that the constructs and data all look exactly the same which makes it difficult to distinguish between the two which makes XSLT more difficult to read than other languges.

A second issue is that the uses for it are more limited than other languages. XSLT is great at what it does; making complicated or radical transformations on XML. But it doesn't apply to as wide a range of problems as other languages, so it is not used as much.

Third, many programming languages have their own libraries for transforming XML. Much of the time when working with XML, only small changes or lookups are needed. The XML is also probably being generated or consumed by a program the developer is already writing in another language. These factors mean that using a language's built in utilities is just more convenient.

Another problem that all of these issues contribute to is inertia. That is, people don't know it, they don't see that they have much need for it, so they avoid it as a solution if there is another option.

What you end up with is a language that is the last choice of many developers when creating solutions. It is likely that XSLT is even avoided when it would be the best tool for the job as a result.