Symphony.

I think XSLT is only overly verbose when you look at the most simple use-cases (for-each, variables, ifs) but (thanks to Xpath) very complex problems tend to boil down to code that isn’t that much more complex than those easy examples.

For example when doing set operations like the following join:

<xsl:for-each select="entry[//data/people/entry[@id = current()/person/@id]]">
   ...
</xsl:for-each>

Most other templating languages would drive you crazy trying to do that.

Oh and why do I like XSLT?

Because of the way it “tickles my brain”. Functional programming is just so much fun! It supports inheritance/overloading, set-operations in a single line, encourages (but doesn’t force) you to not write 100-lines-long templates and excels in solving recursive problems.

Once you get the hang of it all problems become so… simple!

@jonasd: That wasn’t quite my point. Of course if you compare simple expressions character by character XSLT is more “verbose”. But phoque elaborated on what I was trying to say :) Once you start actually solving things in XSLT, you can generally do more with less code which has the bonus of often being more readable as well.

@froded and @phoque — I agree entirely — I’m just playing devil’s advocate and trying to understand why people could have a negative impression of XSLT. At an uninformed glance, the things people usually do (ifs, loops, variables) appear more verbose, so that might cause one to write it off before understanding its numerous advantages.

Looking at phoque’s example, I think it’s not the XSLT-language itself that makes it unpopular for most webdevelopers, but more the lack of knowledge about the power of XPath.

If we could raise awareness about how powerfull XPath can be when trying to achieve complex results in a simple manner, I think that would be a great start to begin with.

It’s “dead” and/or XML is dead

Ruby has been around for a long time.

“Enterprise-y”

Enterprise in your remark is given a a negative connotation. I gather the subtext being that it’s for boring business programming clerks who work in large companies. Enterprise also means it’s robust and an often-used technology, but not widely publicised or portrayed as sexy. In my view, being called “Enterprise-y” is a compliment (although I personally despise the term itself for other reasons.)

Verbose / hard to read

The XSLT as we know it is made up of XSLT instructions and XPath. The XSLT instruction set is indeed more verbose than many other programming languages. “Verbosity” however comes in at various levels. At the lowest level, basic instructions are without contention, more verbose (value-of, choose + when + otherwise, etc.) On a higher level, XSLT is a good recursive language by nature. Coupled with functional language features mean code reuse and rule-based programming style provide many coding conveniences. As such, certain logics can be written in fewer lines in XSLT than other languages. XPath is a very powerful selector language and is very concise.

As far as readability goes, personally I find XSLT easier to read than PHP or JS.

Incurs a performance penalty compared to using only your server-side language of choice

This is true insofar as strictly sticking with only the same language that the system in question runs as it won’t need to instantiate an XSLT processor module/executable. However, all things equal, rendering performance between processing an XML/XSLT document v.s. processing PHP code in PHP would not be as easily distinguishable. In both cases, code are being interpreted and parsed. HTML is a naturally recursive language as such, templates in PHP code will incur overheads that XSLT may not have (i.e. open and close tags are individually declared in PHP whereas it is implied in XSLT.) Furthermore, in most cases, many PHP CMSs sit the template code in a higher level of the system so the parsing is done twice. Once to interpret the template, replacing variables/flags/tags then once more in PHP.

Declarative programming, which most developers aren’t as familiar with / don’t understand

This is very true. My experience has been that non-programmers have always found XSLT less intimidating (and find it easier to grasp) than conventional programmers. This is because programmers need to deconstruct their understanding of procedural programming to understand declarative/functional programming style. The thought, “This is how I do it in PHP, how do I do the same thing in XSLT” is opening up the potential for a world of frustration.

For non-programmers who are familiar with HTML and CSS generally have an easier time. HTML aids in the familiarity of the syntax. CSS aids in the learning of rules and selectors.

In both cases, the main hurdle is the understanding of apply/match templates.

Variable handling seems clunky compared to imperative languages

Immutable variables is a feature of functional programming languages. Mutable variables account for the vast majority of programming logic errors. It is also very hard to trace. Assertion of immutable variables have two advantages: 1) reduction of logic bugs; and 2) the ability for assertion and assumption of result output mid-runtime.

Item #2 is quite powerful, one example Michael Kay provided in his book describes an interesting scenario: Think of a government office that is tasked to monitor traffic congestion. They have a system that renders a map with traffic congestion indicators for an entire state. In a system that relies on mutable variables, the system will need to wait until the system completes execution before a view is rendered. This is because the system cannot assume/assert that a variable/object has completed its mutation until the very last line is executed. In a system who’s variables are immutable, the system is able to render data as instructions are executed. This would result in the ability of a progressive update of the traffic map; imagine a swiping effect, updating data approaching a real-time feed.

Of course, that is not to say that procedural programming is incapable of the feat—asynchronous/parallel processing comes to mind—but the point is to illustrate the difference in its fundamental behaviour. One other benefit of immutable variables is that due to the level of assertions the system can make, it is also able to provide certain levels of optimisation that mutable variable systems cannot.

From Andrew Shooner: Two words: string handling

Nail in the head. XSLT is terrible at string handling (especially without any EXSLT aid). The Symphony best practise is to ensure any heavy string manipulation is done and supplied to the XML before being fed through XSLT.

Right, so here one plus for XSLT I’d like to add: It’s a non-destructive templating language. This is deep and meaningful; think templating system in PHP.

And here is one minus for XSLT: Just like HTML, XSLT is state-based. It doesn’t understand the concept of dynamic loading of XSLT include/imports. This isn’t a problem for most developers however, this is a small issue with something we’re toying with in Symphony 3.

Woah! This is an awesome thread. I feel a little inexperience but from a novice/designer perspective:

• Verbosity - as a non-programmer learning the language, the verbosity is actually a real help as it’s very easy to understand what is going on and read other’s code. The more you get into XSLT the less verbose code becomes too and, as has already been mentioned, quite complex actions can be condensed very quickly with xpath, apply/call templates and recursion. There is often no need to comment code as it’s quite obvious what blocks of code do what (usually).

• Reusability - I have some small experience in other languages but, for me, XSLT makes it really obvious for the novice how to reuse code. apply-templates is just so useful once you get your head around it and encourages a ‘functional’ way of thinking that is often harder to grasp in other languages.-

• Similarity to CSS and HTML - the ease with which you create standards compliant code and the similarity of structure and selectors etc actually made it much easier to learn for me.

• As a backbone for a CMS - I’ve found the opposite to others in terms of finding resources online. Because it’s a standardised language I find loads of great info on line - and you can confidently use stuff you find because i’m not locked into a particular templating system - ie even though wordpress is all PHP all the tags and hooks need to be learned where as with XSLT (and Symphony) all the tags are created by you with a standard syntax.

• Ease of using data - XSLT makes it largely really easy to re-use data from other sources which is a real revelation when coming from other languages - you can just use the exact same principals to interpret an RSS feed or other XML based APIs as you would to display your own data. So handy!-

Basically I’m hooked. I’ve been able to achieve things with XSLT and Symphony that I wouldn’t have had hope of doing this fast in PHP or Ruby or Python. Of course the amazing Symphony community has played a big part in that too :)

I really like XSLT. Actually, Symphony was the reason I started with XSLT and now I more or less do it for a living.

But, having worked with XSLT and XPath 2.0 the last couple of years it’s a struggle every time I sit down to write templates for Symphony.

Long ago (a year or so…) I remember the Symphony crew talked about implementing Saxon through a java bridge. Is this still in the road map? Is there maybe a guide on how to implement this somewhere?

XSLT 1.0 is over 10 years old. I think it’s time for Symphony to step up and do something about it. The problem I guess is that libxslt isn’t gonna help in the near future. But now when XSLT 2.1 is in the pipe, I think that support for 2.0 is crucial for Symphonys survival in the long run.

I like XSLT because when I’m writing it it’s so simple, and powerful, and fast and USEFUL that my brain releases a whole whack of endorphines and it’s rather a lot like eating chocolate or having sex… only clean and tidy.

it’s rather a lot like eating chocolate or having sex… only clean and tidy.

Now that’s a quote for the homepage.

:D

Ever since I figured out that there was CSS and content and that they were two different things, I have been trying to separate the two as much as possible.

What I love about XSLT and Symphony is that the two are completely separate. Its so clean. Page data. Page templates. Its what I’ve been looking for but never knew existed :-)

I love XSLT modes.

I love XSLT (and Symphony) because I (a guy who had only created very primitive/rudimentary websites) was able to successfully develop a website with almost all the functionality I have been wanting to implement. All of it being done by reading a XSLT for dummies book, scouring this website, leveraging all you generous lads, and working on it feverishly for a couple months. Basically, XSLT is super nimble and even a novice web developer can use it to bring ideas into existence.

I didn’t see it here so I thought I would mention: it’s a standard. That means

• More, better documentation.
• The cost of learning XSLT pays off better and longer than other idiosyncratic templating languages because of it’s wide applicability.
• The Symphony dev team’s time is freed by offloading parser development onto the libxslt dev team, allowing them to concentrate on code that’s particular to Symphony. Less code to manage means better code.

That’s off the top of my head. I’m sure there are other benefits to being a standard that I didn’t think of.

@Allen: I agree completely. Lisp is supposed to be dead too, yet people keep on using it, and reinventing features it’s had for decades in their new, hip, languages du jour.

I enjoy it much because of what has already been said. Specifically, I find it a lot easier to read. It may be more slightly verbose then some other proprietary templating languages, but it’s easier to read because of its extra love.

Also, don’t forget that you could change the three letter name space to a single letter and decrease most elements by four characters. That saves a lot of typing when you consider the whole webpage.

Lastly, my other reason for loving XSLT… It’s embraced by Australians.

I love how easy xml and xslt can be learnt, especially since the tags are neutral and not vendor specific, using Liquid XML Editor i also don't have to worry about debugging my xslt, it's all done for me. However I hear that in web standards JSON is now overtaking xml, anybody else heard the same?

However I hear that in web standards JSON is now overtaking xml, anybody else heard the same?

Yes, this is a trend we are keeping an eye on. Whatever the case, XML is not going anywhere. It will remain an important aspect of the Symphony core for defining data structures, etc.

JSON looks to be the future choice for data exchange between services. Depending on the demand and the direction of the web industry, we may implement the ability for dynamic data sources to accept JSON as an input format rather than XML.

Whatever the case, XML is not going anywhere [...] JSON looks to be the future choice for data exchange between services.

I think so too. The only advantage I can see is that JSON is easier to process for JavaScript programs and maybe that it has a bit less overhead.

However JSON has nothing that comes even remotely close to what XSLT can offer.