Does Razor syntax provide a compelling advantage in UI markup?

[Disclaimer: I’m one of the Microsoft developers on MVC and Razor, so I might be a bit biased :)]

We designed Razor to be a concise templating language that uses only the minimal necessary amount of control characters. I would say that large parts of your views can be expressed with fewer characters than the same code using the “traditional” WebForms syntax.

For example the following code snippet in ASPX syntax:

<% if(someCondition) { %>
  <ol>
  <% foreach(var item in Model) { %>
     <li><%: item.ToString() %></li>
  <% } %>
  </ol>
<% } %>

Can be expressed as follows in Razor:

@if(someCondition) {
   <ol>
   @foreach(var item in Model) {
      <li>@item.ToString()</li>
   }
   </ol>
}

While the ASPX version has 21 transition characters (the <% and %>), the Razor version has only three (@)

I would say that the advantages of Razor are as follows:

  1. Concise syntax, which is very similar to the way you write regular C# code (check out the following recent blog post by Phil Haack comparing Asxp with Razor syntax: http://haacked.com/archive/2011/01/06/razor-syntax-quick-reference.aspx)
  2. Automatic HTML encoding of output (which helps protect you from html injection attacks)
  3. Built in (though not 100%) validation of your markup which helps you avoid unbalanced tags

The page-related concepts also map easily from what you have in ASPX

  • As you can see inline code is still allowed
  • Sections (which can be optional) are equivalent to content placeholders
  • Layout pages instead of Master pages
  • The concepts of full and partial views are the same
  • @functions { ... } blocks instead of <script runat="server"> ... </script>

In addition Razor has a number of useful concepts that I would say are better than what is available in ASPX:

  • @helper functions for really easy creation of functions that emit markup
  • @model keyword for specifying your view’s model type without having to write a <%@ Page ... directive with the full class name

I would like to think that we have tackled a real problem, which is to allow you to more easily write concise and standards-compliant views while at the same time providing you with ways to refactor common code.

Of course, not everyone will prefer the syntax which is why we are also fully supporting the ASPX view engine. In addition you can check out Spark and NHaml, which are two 3rd-party view engines that enjoy significant community following. The following blog post has a good comparison of the different offerings: Link

Leave a Comment