Reasons for using XSL when Razor templates exist

Question

Are there any good reasons to continue using XSL templating now that the Razor templating engine exists?

From what I've seen:

1. The Razor templating engine has syntax that is closer to C# (or VB) which is what you already use to write server code, whereas XSL templates have an XML-like syntax which requires the developer to learn at least the basics of XML.
2. You can work directly with your existing object model without having to first convert it into XML.
3. Microsoft only supports XSL version 1.0, so it seems as though you are limited in what functionality you can make use of in XSL.

Note: If you want to respond to this question, please attempt to avoid personal reasons for using one language over the other, and focus on actual technical/practical reasons for why one has an advantage over another. As you have probably already noticed I have already established a preference, but I'm trying to keep this on point the best that I can.

Update

In my current situation, I take data from a database and convert it into XML solely to then use XSLT to transform it into valid HTML, which is then rendered to the user. From my point of view it would seem more practical to convert directly into an object model which would then be used from within Razor templates. Personally I feel it would be easier to maintain and involve less code than my current process. However I'm trying to give XSLT a fair shake before I make a rash decision to convert from XSLT to Razor, and would like a more direct comparison between the two. (Side note: this is not a process I have chosen, but rather one that I'm being told to use.)

Again, please try to not stray too far from the point. My goal is for a technical/practical comparison of XSLT and Razor so that I can determine which technology works best for my situation.

Answer 1

I worked in an organization that relied heavily on XSL when developing ASP.NET forms based applications. When they moved to MVC/Razor XSL was totally dropped. Mostly for reasons 1 and 2 that you listed. From a maintenance standpoint it was easier to just use Razor because new developers coming into the organization could more easily pick up Razor than XSL, and are more likely to already have Razor skills as opposed to XSL. Converting back and forth between objects and XML requires a lot more coding and also working with objects allows you to use InteliSense, which I believe is a big productivity gain. I would also add that using Razor is easier to debug and it is a cleaner and more succinct syntax.

Answer 2

Well, first of all, there are many people for whom a solution so closely tied to one platform is a non-starter, either because they don't use that platform or because they don't want to be tied to it. Your assumption that C#/VB is "what you already use to write server code" surely applies only to a very small part of your audience.

Then there are the people who have come to value the benefits that come from a high-level declarative rule-based approach rather than being seduced by the familiarity of low-level procedural coding. And of course those for whom procedural coding isn't familiar at all.

Agreed, moving between objects and XML can be a pain. For many people, the answer is to not let your data get anywhere near objects. XSLT (you betray your ignorance by calling it XSL) works best when you commit to using XML-based technologies to write your entire application, with C# or Java used only for the plumbing.

But choice of languages will always be a matter of taste. People rarely make objective evidence-based decisions. Fashion prevails; very often the lowest-risk approach for a new project is to use whatever you know best.

Answer 3

Doesn't it depend on what your problem is? We use XSLT to transform XML message documents being exchanged between various systems.

Typically our XLST is executing in a Java EE engine.

So we aren't any where near the MVC/Microsoft use case. Admittedly I have only looked briefly at Razor but it would seem that it has little relevance for our problem domain.