Thoughts On Razor, Microsoft’s New ASP.NET MVC View Engine

This is something I have posted to a private mailing list before, and thought since I have only fixed number of keyboard strokes to death, I should be sharing it with larger audience…

Before Beginning

imageI know some of the audience of this blog may have not even tried ASP.NET MVC, so, you may need to bare with me for a while ((and those familiar with it just bypass this section please).

In ASP.NET MVC, the request goes to a specific method (commonly known as Controller Action) to handle it (choosing which method/action is based on something called Routing, we don’t care about that for now).

Once the method is executed, typically it ends with calling a page or user control (commonly called a View) to send some markup to the browser. Usually this is an ASPX or ASCX file without code behind. It has some special properties to interact with the data coming from the controller action, and some special shortcut methods to write HTML markup (called HTML helpers).

This page can have a master page, include other user controls, and even have a <form runat=server if you want, however, someone may shoot you for doing it in MVC view, because no body uses server controls in MVC. All is using plain HTML/JS (with some helpers to speed the process). Typically you end up having a page that looks very similar to to ASP classic pages, with so many <%.. %> and <%= … %> inside this HTML though, and -depending on how you do it- it can get really ugly.

On View Engines…

Of course, this is not the only way to write the view markup in ASP.NET MVC. ASP.NET MVC enables something called “View Engine”. This View Engine handles finding the view file (whether it is a shared file like master page or .ASPX page or even partial like user control), parsing this view file, and executing any special code parts in it (like the parts inside <%.. %> and <%= … %>). This is not a new idea in ASP.NET MVC, as it existed before in Ruby On Rails and the open source .NET MVC Framework MonoRail.

The community then has taken care of doing alternative view engines. This means ability to write the same markup with different syntax than the ASP.NET syntax we all know (which became known as Webforms View Engine because it’s the same like in web forms development).

Some of there were ported from other MVC frameworks like MonoRail, and some were completely new. Some examples are NVelocity, NHAML, and Spark, which is created especially for ASP.NET MVC and later supported other .NET MVC frameworks like FubuMVC and MonoRail, It tries to make all the code look like html where loops and such can be added as custom HTML tags or attributes. It is also getting the most love from ASP.NET MVC developers not using the default view engine. Go to Spark homepage to get a sense of how the syntax can be different.

Background

After Scott Guthrie, Microsoft’s Most popular Vice President, blogged about the new coming view engine from Microsoft itself code-name Razor, and showed some samples of how your view might look like using it (stating clearly that the webforms view engine will then be obsolete),  this brought many interesting points…

  • There is coming a built in extensibility support for having custom view engines integrated with Visual Studio dialogs. This is great to know, especially if you you see how people suffer to implement some support with the current tooling.

  • Part of this tooling you’ll be able to have multiple view engines set by file extension| for example, enabling you to have multiple view engines in the same project easier. This is typically something you don’t need 90% of the time, but when the rare time comes and you need it, it should be quite handy.

 

Disclaimer:

Razor beta is not even out. All we know about it is from different blogs and twitter conversations. Everything written here may be invalid to some point in the future or completely incorrect.

 

imageThere was a public discussion on twitter between Rob Conery (ex-Microsoft ASP.NET MVC team member, now runs his own business, Tekpub, a GREAT technical videos learning site) and Phil Haack (A popular Program Manager in Microsoft ASP.NET team, mainly focused on ASP.NET MVC, also founder of Subtext, my favorite open source .NET blog engine) about why Razor, why not just give even more VS love to Spark being a very popular ASP.NET MVC view engine (and given the creator of Spark is now a member of ASP.NET team also!). In this conversation Rob said he is more convinced about the decision after a phone call from Phil and some interesting comments (will mention one of them below) were simply deleted after that, as the guys in the private list made me notice. Politics :)

I also got involved in talking to Phil and others about it, but this is another (way much smaller) story…

Finally Getting to the Thoughts…

Mainly the private mail conversation was about Razor, the twitter conversation, and why Microsoft seems to clone open source projects rather than just highlight them to its customers.  Reminded me with something I retweeted few days earlier:

RT @tehlike:RT @hconceicao:RT @chriso:microsofts desire to clone OSS needlessly raises the adoption cost for all other OSS in .NET ecosystem

 

imageI’ll not quote anybody but myself of course:. Usually I’m too lazy when copying things from my mail box, and I think the message is self explanatory now, so, I’ll just quote it and maybe update it later…

You made me notice that @Haacked tweet about jquery is now deleted :D

In case you have been wondering, I mean when he was answering Rob Conery about why Razor, saying that he asked the same guys who started jQuery why not just use prototype.js for their stuff. That was tough!

I understand the case with NHibernate because where it originates from (The Java/JBoss roots, even though they’re not the main director of NH at least now). They had to come with something they own.

I think the jQuery support itself just came because it became the defacto standard all over the web (.NET and others). And because it made their own lives either (developing MS AJAX stuff as jQuery plugins).

But the default is that unless they can acquire it completely (which does not seem to work for OSS stuff for some reason), or they come with their own property. Because they cannot support others. Especially open source. They aim at customers that seek “professional support” here and they want to secure themselves when committing to such.

For Razor itself, I like the cleaner web forms thing, but very scared that they may or may not get this mixed-html-code thing right (don’t think it’s easy, tell me all the dynamic kids are doing so, but still.. I’m not sure MS will do it right). Also I hate “@”, even more, I hate having to escape “@” with “@@” if followed by some text that the parser can understand as code. This is really ugly. Much love the Spark ${ } style, but they won’t do something similar, as they want to escape { } / < > / <% %> open/close style. Just hope they change “@” to something less common and get the parser right.

There is a website for HTML templating stuff I’m building for a friend for some time now (paused as the friend had a higher priority project for me now). People are uploading HTML files that include Spark syntax (against a defined model with user friendly property names) and I created a couple of helper classes to read the files, get Spark engine to translate them.

It was very easy for the test designers to get started with it and they loved it that a friend designer wanted all templating stuff (email templates, etc..) in the current active project we’re doing together to use Spark also. I will probably use Razor for MVC stuff, but not abandon Spark as a great templating engine.

 

Spotting the Positives / New Stuff

Not sure whether this part should have come first, but to be fair, there are some good “NEW” parts expected to come with Razor. I have referred one on twitter in a reply to @Orangy (the main guy behind Resharper, the must-have plug-in for all Visual Studio Versions).

Quoting from Phil HAack’s post on Razor:

one benefit that I look forward to is that unlike an ASPX page, it’s possible to fully compile a CSHTML page without requiring the ASP.NET pipeline. So while you can allow views to be compiled via the ASP.NET runtime, it may be possible to fully compile a site using T4 for example. A lot of cool options are opened up by a cleanly implemented parser.

Also, Scott Guthrie put a comment reply to his own post about why Razor may be better for unit testing your views (if you think you want to):

The Razor parser and view engine can be instantiated and used outside of the ASP.NET application domain.  This means you can directly instantiate and use it within a unit test project without any dependencies on running ASP.NET. 

From a unit testing perspective you can indicate the view template you want to run, supply it with any dependencies, and then pass your own test models/viewmodels to it and have it run and render back a string to you. You could then verify that the correct content came back.  This would isolate the views from your controllers and any data access, and allow you to also isolate them from the runtime environment.  View engines in ASP.NET MVC VNext (both Razor and the .ASPX one) will also support and integrate with dependency injection as well.

Different people have differing opinions about the usefulness of verifying the HTML that comes back from a view using unit tests.  For scenarios involving a lot of javascript something like browser based testing is probably better.  But for basic coverage it can be useful.  It also helps verify that you don’t have compile errors or other runtime boundary errors with your views.

 

It’s worth mentioning that the guy writing the Razor parser seems to be a really smart fun guy. See his own writing on the parser.

Other (Better) Notes I Have Read

Some of the people who shared similar notes and I agree with (to different extents)…

 

So, now, what are your own thoughts?

Share With Friends:

P.S. Please help me out by checking this offer, then look below for a small Thank You.

How did I learn that?

As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.
It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2, ASP.NET 5, and other fullstack developer goodies.