ASP.NET MVC View Engines (Community Wiki)
Since a comprehensive list does not appear to exist, let's start one here on SO. This can be of great value to the ASP.NET MVC community if people add their experience (esp. anyone who contributed to one of these). Anything implementing IViewEngine (e.g. VirtualPathProviderViewEngine) is fair game here. Just alphabetize new View Engines (leaving WebFormViewEngine and Razor at the top), and try to be objective in comparisons.
System.Web.Mvc.WebFormViewEngine
Design Goals:
A view engine that is used to render a
Web Forms page to the response.
Pros:
- ubiquitous since it ships with ASP.NET MVC
- familiar experience for ASP.NET developers
- IntelliSense
- can choose any language with a CodeDom provider (e.g. C#, VB.NET, F#, Boo, Nemerle)
- on-demand compilation or precompiled views
Cons:
- usage is confused by existence of "classic ASP.NET" patterns which no longer apply in MVC (e.g. ViewState PostBack)
- can contribute to anti-pattern of "tag soup"
- code-block syntax and strong-typing can get in the way
- IntelliSense enforces style not always appropriate for inline code blocks
- can be noisy when designing simple templates
Example:
<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) { %>
<ul>
<% foreach(var p in model){%>
<li><%=p.Name%></li>
<%}%>
</ul>
<%}else{%>
<p>No products available</p>
<%}%>
System.Web.Razor
Design Goals:
Pros:
- Compact, Expressive, and Fluid
- Easy to Learn
- Is not a new language
- Has great Intellisense
- Unit Testable
- Ubiquitous, ships with ASP.NET MVC
Cons:
- Creates a slightly different problem from "tag soup" referenced above. Where the server tags actually provide structure around server and non-server code, Razor confuses HTML and server code, making pure HTML or JS development challenging (see Con Example #1) as you end up having to "escape" HTML and / or JavaScript tags under certain very common conditions.
- Poor encapsulation+reuseability: It's impractical to call a razor template as if it were a normal method - in practice razor can call code but not vice versa, which can encourage mixing of code and presentation.
- Syntax is very html-oriented; generating non-html content can be tricky. Despite this, razor's data model is essentially just string-concatenation, so syntax and nesting errors are neither statically nor dynamically detected, though VS.NET design-time help mitigates this somewhat. Maintainability and refactorability can suffer due to this.
No documented API, http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Con Example #1 (notice the placement of "string[]..."):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
Bellevue
Design goals:
- Respect HTML as first-class language as opposed to treating it as "just text".
- Don't mess with my HTML! The data binding code (Bellevue code) should be separate from HTML.
- Enforce strict Model-View separation
Brail
Design Goals:
The Brail view engine has been ported
from MonoRail to work with the
Microsoft ASP.NET MVC Framework. For
an introduction to Brail, see the
documentation on the Castle project
website.
Pros:
- modeled after "wrist-friendly python syntax"
- On-demand compiled views (but no precompilation available)
Cons:
- designed to be written in the language Boo
Example:
<html>
<head>
<title>${title}</title>
</head>
<body>
<p>The following items are in the list:</p>
<ul><%for element in list: output "<li>${element}</li>"%></ul>
<p>I hope that you would like Brail</p>
</body>
</html>
Hasic
Hasic uses VB.NET's XML literals instead of strings like most other view engines.
Pros:
- Compile-time checking of valid XML
- Syntax colouring
- Full intellisense
- Compiled views
- Extensibility using regular CLR classes, functions, etc
- Seamless composability and manipulation since it's regular VB.NET code
- Unit testable
Cons:
- Performance: Builds the whole DOM before sending it to client.
Example:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
Design Goals:
NDjango is an implementation of the
Django Template Language on the .NET
platform, using the F# language.
Pros:
NHaml
Design Goals:
.NET port of Rails Haml view engine.
From the Haml website:
Haml is a markup language that's used
to cleanly and simply describe the
XHTML of any web document, without the
use of inline code... Haml avoids the
need for explicitly coding XHTML into
the template, because it is actually
an abstract description of the XHTML,
with some code to generate dynamic
content.
Pros:
- terse structure (i.e. D.R.Y.)
- well indented
- clear structure
- C# Intellisense (for VS2008 without ReSharper)
Cons:
- an abstraction from XHTML rather than leveraging familiarity of the markup
- No Intellisense for VS2010
Example:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
Design Goals:
A view engine based upon
NVelocity which is a .NET port
of the popular Java project
Velocity.
Pros:
- easy to read/write
- concise view code
Cons:
- limited number of helper methods available on the view
- does not automatically have Visual Studio integration (IntelliSense, compile-time checking of views, or refactoring)
Example:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
Design Goals:
SharpTiles is a partial port of JSTL
combined with concept behind the Tiles
framework (as of Mile stone 1).
Pros:
- familiar to Java developers
- XML-style code blocks
Cons:
Example:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark View Engine
Design Goals:
The idea is to allow the html to
dominate the flow and the code to fit
seamlessly.
Pros:
- Produces more readable templates
- C# Intellisense (for VS2008 without ReSharper)
- SparkSense plug-in for VS2010 (works with ReSharper)
- Provides a powerful Bindings feature to get rid of all code in your views and allows you to easily invent your own HTML tags
Cons:
- No clear separation of template logic from literal markup (this can be mitigated by namespace prefixes)
Example:
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">${p.Name}</li>
</ul>
<else>
<p>No products available</p>
</else>
<Form style="background-color:olive;">
<Label For="username" />
<TextBox For="username" />
<ValidationMessage For="username" Message="Please type a valid username." />
</Form>
StringTemplate View Engine MVC
Design Goals:
- Lightweight. No page classes are created.
- Fast. Templates are written to the Response Output stream.
- Cached. Templates are cached, but utilize a FileSystemWatcher to detect
file changes.
- Dynamic. Templates can be generated on the fly in code.
- Flexible. Templates can be nested to any level.
- In line with MVC principles. Promotes separation of UI and Business
Logic. All data is created ahead of
time, and passed down to the template.
Pros:
- familiar to StringTemplate Java developers
Cons:
- simplistic template syntax can interfere with intended output (e.g. jQuery conflict)
Wing Beats
Wing Beats is an internal DSL for creating XHTML. It is based on F# and includes an ASP.NET MVC view engine, but can also be used solely for its capability of creating XHTML.
Pros:
- Compile-time checking of valid XML
- Syntax colouring
- Full intellisense
- Compiled views
- Extensibility using regular CLR classes, functions, etc
- Seamless composability and manipulation since it's regular F# code
- Unit testable
Cons:
- You don't really write HTML but code that represents HTML in a DSL.
XsltViewEngine (MvcContrib)
Design Goals:
Builds views from familiar XSLT
Pros:
- widely ubiquitous
- familiar template language for XML developers
- XML-based
- time-tested
- Syntax and element nesting errors can be statically detected.
Cons:
- functional language style makes flow control difficult
- XSLT 2.0 is (probably?) not supported. (XSLT 1.0 is much less practical).
