Editor’s note: Welcome to .NETRocks Conversations, excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 606, with Phil Haack, a program manager with Microsoft's ASP.NET team, who discusses the new features in ASP.NET MVC 3.

Carl Franklin: We are very happy to welcome back to the show Mr. Phil Haack. As a code junkie, Phil loves to craft software. Not only does he enjoy writing software, he enjoys writing about software and software management on his blog at haacked.com. Phil is a program manager with the ASP.NET team working on ASP.NET MVC. Phil, how are you?

Phil Haack: I'm doing great. How are you guys?

CF: Doing wonderful. Can I ask you a question?

PH: Sure.

CF: What is Razor?

PH: What would you have done if I said no?

CF: I would say thank you, it's been a great show.

PH: Yeah. It's a tricky question. Razor is the new syntax for doing views and simple web pages. It's been used by a new product that we've come out with the beta called ASP.NET Web Pages, a simple inline page development framework for doing simple web applications.

But that same syntax also is in use by ASP.NET MVC 3 in the new view engine we wrote that is based on that syntax, what we call the Razor View Engine. So if you're familiar with MVC, you know we have support for having custom view engines, multiple different kinds of view engines. With MVC 3 we're sort of making the Razor view engine a default, but we still include the existing Web Forms view engine, too.

CF: In Razor you can always tell a Razor by the "at" sign. That's sort of the marker.

PH: Yeah. The "at" sign is really big in Razor. What's really unique about Razor is that with most view markup syntax, you have sort of concrete delimiters between code and markup. You have the same as less [than] percent and percent greater than, and it's pretty much you know that anything between that is code and anything outside of that is not code. But with Razor, what we try to do is actually minimize the noise of these delimiters by having a single delimiter, the "at" sign, but you don't have to limit the end of code blocks. Instead, we understand the structure of code and the structure of markup, and we're able to seamlessly transition between the two based on what you're writing.

Richard Campbell: That basically means the moment you hit angle brackets, you know you're back in HTML.

PH: Yeah, exactly. If you use the other syntaxes, it takes a little bit of getting used to, to but once you start writing it, it almost flows, as I like to say, it almost flows the way you think. And with MVC 3, with the latest version of Razor, it gets even better. One of the tricky things about mixing code at markup is what happens when you have functions that return markup. Right?

CF: Right.

PH: So let's say I want to write a magnificent div generator, and it's just a C# function that returns this really cool div tag. I don't know what that looks like, but just take my word for it.

CF: Yeah.

PH: So you start return, and you create a new string with the double code div, IDE quotes. Now you need to escape the quotes, or if you use the "at" sign at the beginning of the string to specify a literal string, you give it double quotes. It starts to look really messy, especially if you start taking user input and concatenating it to that string, then you have to make sure you HTML code that user input, and so on. So writing these functions, they look really ugly. What would be nice is if you could write a function but use HTML as part of the body of the function when you actually want to return HTML, almost like XML literals in VB.NET.

CF: Right.

PH: And so with MVC 3 beta with the new Razor, we had this "at helper" syntax. With at helper you can write functions, and in the body of the functions you could return, and then you could just code open brace and be in HTML mode and create a little template of HTML right in the body of that method, and do it the same way you would rather view in MVC. So it becomes really nice for building this little helper method that returns snippets of HTML.

CF: So my next question is, do we need MVC to get Razor?

PH: No. If you install ASP.NET Web Pages or WebMatrix, you can actually use Razor in an inline fashion. So the way that works is that if you just write it, let's say Index.cHTML, you could start putting code and Razor markup right in there, and then just make a request for that page, and it just works. So you can use Razor outside of MVC.

CF: Does that mean that we need to use the WebMatrix tool, or you just have to install it to get the code support? Can I use Notepad if I want to?

PH: Oh, yes. You can use Notepad. I mean, the WebMatrix code just gives you extra support. It gives you some amount of syntax highlighting and IntelliSense.

CF: Right. And if I want to use Visual Studio, I could use that too?

PH: Sure. Currently we don't have support yet for syntax highlighting and IntelliSense for Razor syntax, but that's coming.

CF: Tell us about some of the other enhancements in ASP.NET MVC 3.0 beta. I'm thinking of the unobtrusive JavaScript in HTML 5.0 feature.

PH: So if you look at our current client validation in MVC 2, the way it works is that you attach metadata to your server objects, and then we spit out this blob of JSON into your view. Then we have some client script that then attaches to, reads all that JSON metadata and then attaches validation to all the client code.

CF: Nice.

PH: And the problem with that is that you have to meet this JavaScript into your page. So unobtrusive JavaScript is really about writing clean markup that works without JavaScript enabled and then using a separate JavaScript that's not inline to the page unobtrusively or using the content of progressive enhancement enhancing that page so that it now works with that JavaScript library.

Typically, if you are writing the sort of very purist approach where you just write markup and then you write the separate script that you're referenced at, like it knows your markup patterns, and then add that behavior, [it] layers that behavior on. However, with what we're doing since we're doing a more general-purpose foundation library, we're taking advantage of HTML 5.0 attributes, the so-called Data Dash DAR attributes. When you have unobtrusive JavaScript enabled, instead of sending that blob of JSON with all the metadata validation, instead when we render out things like the textbox or the various form inputs, we actually render out the Data Dash attributes with things like this is required, here is the error message, and so on. Then we have this jQuery validation plug-in that then reads the attributes on the page if you reference it, then calls into jQuery validation and hooks up jQuery validation.

CF: Okay.

PH: What's really cool about that one is there's nothing specific to MVC in there, which is great. The first time Brad Wilson, who wrote a lot of that code, demonstrated this, he just started with the plain old HTML page, added some Data Dash attributes, referenced three scripts, jQuery, jQuery validation and an unobtrusive library, and boom, there's client validation support.

CF: Wow.

RC: This is pretty cool.

CF: Yeah, it is.

RC: But I'm also really excited with the idea that people are underestimating the impact HTML 5.0 is going to have for us as developers as we start sort of trying to figure this out. So I like the idea that you may be taking some of this for us, that we're going to keep building apps the way we always have and it's just going to spit out some HTML 5.0.

PH: Yeah. So one of the nice things about relying on the Data Dash attributes is that even if your page is—even if your browsers don't support HTML 5.0, well, those attributes are purely metadata. Your browsers will still have that attribute part of the metadata, and so the client validation will still work even if your browser doesn't support HTML 5.0.

There's much more! Listen to or read the full interview here.

Richard Campbell and Carl Franklin (both Microsoft Regional Directors) are the voices and brains behind .NET Rocks! (www.dotnetrocks.com). They interview experts to bring you insights into .NET technology and the state of software development. They’re more than dry technical interviewers—they have fun!