I'm in the early stages in the design of a system that will essentially be split into two parts. One part is a service and the other is an interface with the service providing data through something like OData or XML. The application will be based on the MVC architectural pattern. For the views, we are considering using either XSLT or Razor under ASP.NET.

XSLT or Razor would help to provide a separation of concerns where the original XML or response represents your model, the XSLT or 'Razor view' represents your view. I'll leave the controller out for this example. The initial design proposal recommends XSLT, however I suggested the use of Razor instead as a more friendly view engine.

These are the reasons I suggested for Razor (C#):

  • Easier to work with and build more complicated pages.
  • Can easily produce non-*ML output, eg csv, txt, fdf
  • Less verbose templates
  • The view model is strongly typed, where XSLT would need to rely on convention, eg boolean or date values
  • Markup is more approachable, eg nbsp, newline normalization, attibute value normalization, whitespace rules
  • Built in HTML helper can generate JS validation code based on DTO attributes
  • Built in HTML helper can generate links to actions

And the arguments for XSLT over razor were:

  • XSLT is a standard and will still exist many years into the future.
  • It is hard to accidentally move logic into the view
  • Easer for non programmers (which I don't agree with).
  • It's been successful in some of our past projects.
  • Data values are HTML-encoded by default
  • Always well formed

So I'm looking for aguments on either side, recommendations or any experience making a similar choice?

  • 9
    XSLT has people arguing in favor of it in 2011? Aug 29, 2011 at 16:28
  • 6
    when someone asks XSLT or ... the correct answer is to interrupting immediately after they say OR with "the second one!" XSLT while being supported in many many places is a special hell to work in compared to almost any other option than cobol or assembler. Use XSLT only when all modern alternatives have been eliminated.
    – Bill
    Aug 29, 2011 at 23:17

6 Answers 6


I HAVE successfully used XSLT as a web presentation tier... in 1999. In the last 12 years, much better options have come along. Do yourself a big favor, and use Razor. It's a pleasure.

  • Hey - would you mind saying what other options apart from Razor do you have in mind?
    – Bartosz
    Mar 27, 2018 at 13:55
  • This answer was a long time ago, so I don't quiet remember what I had in mind. But even classic ASP would work better than XSLT, IMO. Currently we have moved to Angular.
    – afeygin
    Mar 27, 2018 at 20:58

Here is a basic syntax comparison


@foreach(var item in View.List) {


  <xsl:template match="/">

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>


The data sources for the two examples


<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
        <name>List item one</name>
        <name>List item two</name>


ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
  • 4
    I realize this is dead and over, but couldn't help remarking that your own answer here is the perfect argument for why YOU [hopefully went] with Razor and not XSL: you're clearly more comfortable with the imperative programming paradigm that Razor sticks to versus the declarative (quasi-functional) model that XSLT is at its best (& hardest) in. e.g. instead of template matching name (possibly dropping to a different mode), you ran a for-each across it from item. While this technically works, it fails to play to XSLT's strengths. This should not be downplayed as a (personal) argument.
    – taswyn
    Jul 17, 2015 at 20:41

Is there a 1:1 relation between HTML pages and XML output? Consider following cases:

  • Strong correlation: each web page has an HTML and a corresponding XML form.

Example: you're hosting a website with movies reviews. You have a home page with latest reviews, one page per review and a page with guests comments and ratings. There is no registration whatsoever. You want to make it easy to use your website programmatically without the ugly HTML parsing. In this case, you can have a 1:1 relation: all the human can do, the bot can do too: with same requests, they will obtain the same content.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau is used by humans.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml is used by bots to access the same information.

  • Weak or no correlation: there is just a bunch of web services on one side, and a bunch of web pages on the other.

Example: you're a creator of another Facebook. There is a website, and there is an API. The only common point is that the same database is used, but bots cannot access what people can, and the information is presented differently.

http://example.com/MyFriends/ shows the top ten of friends I have in my account. By clicking "More", an AJAX request is made, showing other friends.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml shows the corresponding XML with all friends I have.

You can see that:

  • The API is hosted separately, on a distinct server,
  • The relation between pages and API is hard to see.
  • The website needs to use sessions to track logons. The API needs just a generated key to be sent on every request.
  • The number of requests is not the same. In one case, you have to query the page, then do an AJAX request to obtain the rest of your friends. In other case, you obtain the whole list at once.
  • The returned information is not the same. As a human, you identify your friends by their name. A bot using the API will identify them by their unique identifier which you may never see on the website.

I recommend choosing XSLT only if you are near a 1:1 relation. In this case, it will simplify the approach: the application will emit XML every time, but sometimes transform it with XSLT for the browsers.

If you don't have this relation, I don't see any benefit of XSLT over Razor. It provides a separation of concerns which Razor provides too. It allows you to modify HTML without the need to recompile the website, which Razor allows too.

As for the benefits you listed:

XSLT is a standard and will still exist many years into the future

Are you planning to make an application which will live for a very long time? Razor have chances to be used in four years, or at least be supported. The lifespan of most applications is less than four years, so...

Easer for non programmers (something which i could contend with).

Wait, what?! Even programmers find that XSLT sucks, is difficult to understand and to use. And when I talk to non-programmers about XML (not even close to XSLT), they cry and run away.

It's been successful in some of our past projects.

If your team never used Razor before, then consider the time required to learn it.

If your team used it, but those projects failed, consider analyzing why is it failed and was it because of Razor, and what could you do to avoid such failures in future projects.

  • I'm not sure if it's 1:1 some pages may use multiple xml models merged. Aug 29, 2011 at 11:45
  • @Lavinski: see the edit. I tried to explain a bit better the difference I make between 1:1 and other cases. I hope it helps you to see to which case belongs your specific project. Aug 29, 2011 at 20:22
  • Why do you say that Razor is going to be used for 4 years?? Also, as a side note, I think that 4 years is a very short time for an app lifetime and if I were to choose a technology which will be supported for 4 years, I wouldn't even bother reading the quickstart guide:D
    – Bartosz
    Mar 27, 2018 at 14:27

My recommendation is Razor and the main reason is that it's much more easier to work with (than XSLT, and opposite to your enumerated argument in favor of XSLT, though, you're on my side). I have experience of working with both and Razor becomes exceptionally powerful in conditional statements, declarative helpers (functions in principal), branching, looping, etc.

After all, let's not forget Razor is a programming language (yeah, a template engine, or view engine, but implemented via a programming language like C# or VB.NET), while XSLT is more have a markup structure.

I think your scenario is like trying to select C# or T-SQL to write a complex business application. While T-SQL is pretty powerful in set operations, it simply breaks when you try to implement logic (if-else, switch, for, etc.) in it.


You don't have to choose, you can use both. In ASP.NET MVC you can use multiple view engines at the same time. In the project I'm currently working on I'm using XSLT for readonly views and Razor for forms. You can also use XSLT with Razor layout or Razor with XSLT layout. I'm using XSLT layout, so I simply use a Razor layout that calls the XSLT layout and passes the sections HTML as parameters:

   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }

... and in htmlRaw.xsl you simply use disable-output-escaping="yes":

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>

See Using Razor and XSLT in the same project.


I would suggest there's a third and better way: put two different thin front ends on top of a single service/application layer which has no UI as such.

So, rather than

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model


UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

and ensure that the UI and Service contain ONLY code that is unique to that interface. (apologies for the ASCII diagrams, best I can do right now)

The reason I would be concerned about either of the designs you are discussing is that it ties development of the user interface to development of the service, which is rarely how you want to work. If the business wants to add a piece of functionality to the user interface, you don't want to be forced to write that service before you can do it. You want to write the user interface part and then, assuming it is required in the service, reuse the code there.

Worse, if the business wants to display data very differently to the end-user from how it is presented to a mechanical user via the service (which seems highly likely), you're going to have to start putting complex code into XSLT, or build a second service layer (or worse, fat controllers) on top of your service to represent presentation to the user.

Think about validation in this case. You are potentially drawing three levels of trust. Your model will require validation to make sure you don't store invalid data; then your service may require some more validation, to ensure that external consumers don't try to do something they're not allowed to do; and your UI will need some validation rules, at best so that it can avoid a postback.

And this is before we even touch the sticky situation of something which should not be allowed through the API but should be allowed through the UI, which requires the API.

I have heard an argument that running your UI through your service is dogfooding and thus good for the quality of the service, but I strongly suggest there are better ways to do that while keeping a solid (and SOLID) separation of concerns between the service, the UI and the business model.

All this said, if you must go the way of wrapping your service with a UI, I would strongly recommend Razor over XSLT.

XSLT is a standard, yes. But XSLT 2.0 still has limited support, so you're stuck with an outdated standard if you want to make that argument.

XSLT is not easy to read. By anyone that isn't an XSLT expert. Who do you think is easier to find, when you need to hire new staff? Someone claiming to be an XSLT expert or an ASP.NET for MVC expert?

And yes, I have seen XSLT used successfully, but only before MVC for ASP.NET was an option.

  • The layers in the question are not really final, they are just some background, the focus is razor. Aug 29, 2011 at 23:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.