Alternative ASP.NET MVC View Engines

ASP.NET MVC uses what is called a “View Engine” to render content to the user’s browser. There are a growing number of view engines available, so I’m just going to cover what seem to be the three most popular.

Standard (.aspx)
Not going to cover this one, as this is more a post about the alternatives that are out there. I may refer to the differences between the alternative engines and the original engine as I go along, but I’m going to leave out the Standard engine for now.

The Razor view engine is sort of Microsoft’s official “advanced” view engine, which comes packaged with MVC3. Scott Guthrie, the Vice President of the Microsoft Developer Division has blogged about the details of the engine here.
Razor is definitely my favourite of the view engines, so this blog post might descend a little bit into a discussion of why the other view engines aren’t quite as good as Razor.

I’m just going to cover some of the basics:
Razor essentially allows you to seamlessly introduce code elements into markup without having to surround code blocks with “<%” as in the standard view engine. Using the “@” character, the view engine is parsed intelligently by the runtime to determine what is a presentation element and what is a code element.

For example, the code:

<h1>Hello <%=name %>, the year is <%= DateTime.Now.Year %></h1>
<% foreach(var p in products) { %>
<li><%=p.Name %> (£<%=p.Price%>)</li>
<% } %>

would become a much more readable:
<h1>Hello @name, the year is @DateTime.Now.Year</h1>
@foreach(var p in products) {
<li>@p.Name (£@p.Price)</li>

But both would result in exactly the same thing being rendered. This allows a developer to write a much neater, more concise and compact view when they are developing a page and allows front-end developers to alter markup without getting a headache.

I’ll be honest… I don’t really get nHaml. I don’t know what it brings to the table. It’s slightly less verbose than the standard view engine, but it implements its own replacement for HTML markup and ends up looking pretty unattractive.

Here is the example from Razor, translated to nHaml:
= name
, the year is
= DateTime.Now.Year
- foreach(var p in products)
%li= p.Name + “(£” + p.Price + “)”

I don’t know why anyone would want to write views like that… but apparently people do!

Spark is probably a bit of a step up from nHaml, but again, I think the markup comes out looking quite unattractive and definitely doesn’t lend itself well to separation of concerns, as all of the code is essentially just written using XML tags.

Again, the same example from Razor, translated to Spark:

<h1>Hello ${name}, the year is ${DateTime.Now.Year}</h1>
<for each="var p in products">
<li>${p.Name} (£${p.Price})</li>

While I think this is slightly more readable than the nHaml variation, it’s still somewhere close to a front-end developer’s nightmare. It adds in all sorts of non-existent tags and attributes, and is likely to end up cluttered.

Maybe I’m wrong about the benefits of the alternative view engines, but Razor seems miles ahead of any of the others in terms of maximizing the developer’s ability to mix code with markup, while avoiding frustrating front-end developers.

If you are interested in the other MVC view engines out there, there’s a good compilation here.