ASP.NET MVC Razor view engine

Question

After reading Scott Guthrie's blog entry about the new Razor view engine for ASP.NET MVC and reading this question comparing the available view engines.

Razor seems to address most of the problems with the default view engine. What feature differences would make it a compelling choice for you as a developer? What features are lacking that would keep you from using it?

Tallage

I think so. But man, Razor can't get here soon enough. – Soane

Answer 1

There's much more to view engine except markup language. Few Spark features that I will miss:

• write html extensions using same markup language, not C# (macros) - I see that Razor also supports this, I hope it supports method/parameters override;
• custom tags (write _Tag.spark to use <Tag />);
• autogenerated variables like varIsFirst, varIndex, etc;
• special expression forms (?{} for conditional attributes, $!{} to skip errors, etc);
• nice master/partial layouts support, including ability to specify in partial that part of markup should be render only once in master (e.g. script includes);
• you can still have WebForms markup - great for compatibility and incremental upgrade;
• support to use both "" and '' quotes inside each other (extremely useful).

I like Spark syntax for loops/ifs more - mixing HTML <> and C# {} braces doesn't look too nice - but that's purely personal opinion.

There're very promising features in Razor, too, e.g. inline templates. Given that Spark creator was hired by Microsoft, I think there's a hope for Razor to be well written, very useful, and well supported view engine. Of course I won't re-write hundreds of my Spark views with Razor (though I did rewrite dozens of my WebForms views with Spark). But I will surely take a serious look at Razor - I only found this out from your questions, thanks - and what I see now looks promising. It doesn't compete with WebForms, of course (any view engine is better than WebForms), but it looks like a good choice for a new ASP.NET MVC project, if you haven't yet invested into another view engine too much.

Oxcart

re: 'autogenerated variables' - you can use John Skeet's very clever 'SmartEnumerable' class to achieve this with razor / webforms: yoda.arachsys.com/csharp/miscutil/usage/smartenumerable.html – Transfuse

Answer 2

Unit Testable: The new view engine implementation will support the ability to unit test views (without requiring a controller or web-server, and can be hosted in any unit test project – no special app-domain required).

At last!!! Can't believe it took almost 8 years for Microsoft to finally bring a view engine that supports this.

Florance

Answer 3

For me there are three compelling reasons:

1. Compilation - Razor views can be compiled into a DLL. At last we get proper re-usability in .NET web projects. I can have a business object that knows how to display itself without having that code floating around as .ascx files in some part of the web project.

2. Testability - as it's compiled to a class I can write a unit test and throw mocked instances of objects at it to see if the HTML is right.

3. IntelliSense and the Terse Syntax are nice but not the most important parts.

Bouie

do you have more information on the 'Compilation' in your bullet points? A link, perhaps? Thanks, in advance. – Gaol

Yes, it was mentioned in the comments to ScottGu's blog article about Razor that support for class library was planned: weblogs.asp.net/scottgu/archive/2010/07/02/… Quote: "re: Introducing “Razor” – a new view engine for ASP.NET Saturday, July 03, 2010 12:14 PM by ScottGu @Chris, > 1) Can these be precompiled or embedded into the assembly as a resource? Yes - that is one of the things we are looking to enable that I didn't mention in the post. We plan to enable you to add these to class library projects and compile them into assemblies. ... ScottGu" – Bouie

Ah, no wonder I didn't see it...always millions of comments on his posts. :) Thanks – Gaol

Update on this: a couple of good blog articles on creating Razor views outside of ASP.NET projects: blog.andrewnurse.net/2010/07/22/… – Bouie

Precompiling is not available in rc1 yet, though it's possible to create something yourself. I just blogged about that: goo.gl/KffWq – Pyrolysis

Answer 4

Obviously I haven't evaluated it in practice yet, but the fact that it is terser than the ASPX engine is the most compelling feature to induce a switch. I only hope that it also auto-formats more nicely. The fact that it will be supported with intellisense and delivered with MVC makes it a natural choice for starting new projects. I'm going to give it a fair shot on a small project before I make the switch. Just from reading the article I didn't see anything that I wouldn't be able to do with it that I'm currently doing with the ASPX engine.

Update: I've been using Razor for well over a year now and would never go back to the ASPX engine. The syntax seems very natural and expressive.

Nosedive

Have you considered using Spark? See queen3's answer for a list of additional features Spark provides. – Adjuvant

Unfortunately Spark Intellisense support is not as good (esp. in VS2010) and this can be a show stopper for many developers. But the support is being developed so hopefully things will be improved. – Oxcart

I kind of feel like if you need Intellisense in a view you're making something too complicated. Granted, 90% of the content of my views looks like !{Html.EditTemplateFor(x => x.Quantity)} so I only need to know a few key helper methods and the properties on my view model. I think a lack of Intellisense has actually helped me keep things simple. – Adjuvant

Answer 5

Besides the cleaner look, the flexibility of the layout sections looks very good, and the declarative HTML helpers look very useful. So far don't see any downside in using it but of course will have to give it a try in practice.

Pilliwinks

Answer 6

Razor use Brackets, that is, for foreach stuff. Spark uses here XML tags.

So, Spark completely supports parsing and analysing of a view file per XML processor.

Mabye that's not a big thing, but shows consistency and extensibility.

Cenis