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

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 actu开发者_高级运维ally easier once you are comfortable with the syntax?

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#.

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.

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).

The choice between XSLT and .Net components in Sitecore is largely one of taste and skillset. XSLT in Sitecore does have some drawbacks though - it tends to be outperformed by .NET components for all but the most simple renderings and the places where it might seem most logical to use it, such as replicating content tree structure as a site menu, are actually those that tend to take the biggest performance hit. In the right situations XSLT is an incredibly powerful tool and well worth learning, but I've yet to see a convincing argument for making much use of it in Sitecore. It's also worth noting that some of the standard patterns of XSLT programming aren't the most efficient in Sitecore.

The only real advantage I can think of, would be that XSLT renderings are easier to deploy in isolation. Say, for instance, that you're updating your "News Spots" rendering and you want to deploy this change to test/production right away - it would be a simple case of uploading the .xsl file itself.

Using .NET development (and enduring the Web Application Project model), a deployment of the code base would implicitly deploy any and all changes to the affected assemblies - including whatever work you have in progress.

There are, of course, ways you can manage this. Source code branching/merging and so on - but that's an additional layer of complexity to your solution.

That being said, I use .NET for well over 95% of all my Sitecore development myself :-)

"In summary, a primary goal of software design and coding is conquering complexity. The motivation behind many programming practices is to reduce a program's complexity. Reducing complexity is a key to being an effective programmer." -Steve McConnell (1993)

Let that guide when to use XSLT over C#.