What are the advantages of using XSL in Sitecore instead of C#?

Question

While learning Sitecore I have found that the majority of Sitecore sample code on the web is in XSL instead of .NET.

What would be the advantage of choosing XSL over the processes I have become accustomed to as a .NET developer?

Are there processing speed advantages to using XSL?

Is XSL actually easier once you are comfortable with the syntax?

Answer 1

I'll just add my 2 cents too:

I find that there are too many limitations in XSLT that need to be overcome with either external "libraries" or with you developing a method in C# that can be used in XSLT.

So I find using Asp.Net simpler. But then I'm also a lot better with Asp.Net than with XSLT.

But XSLT has some good things:

• good when getting fields from the current context item
• good with simple content etc.
• doesn't force the solution to recycle/rebuild
• usually a nice way it fails, ie. the page still works, but the xslt that failed says it fails

When I first started working with Sitecore, my company used quite a bit of XSLT, but we've slowly gone away from that, because of it's limitations and because most people here are more familiar with Asp.Net/C#.

Answer 2

Some folks prefer XSL because of existing team skill set, the availability of XSL talent, or the belief that XSL is easier or cheaper to learn.

In Sitecore, ASP.NET-based sublayouts actually perform much better than XSL renderings. If that's what you are comfortable with, go for it. I've never created an XSL rendering myself.

Answer 3

XSLT is a powerful language; its main advantages over languages like ASP.NET tend to come when you want to reuse and customize logic over a wide variety of different pages or different source document structures with common shared elements and other variable structures. To achieve this it uses a rule-based processing model which some people find quite difficult to get to grips with on first encounter. Learning it is an investment that will pay off over time, but it can be daunting at first.

As for performance, I've never come across a site where it isn't fast enough for the job, and that includes some pretty high-stress services; when people have had performance problems they've usually turned out to be in other parts of the processing pipeline (or simply due to bad coding).