Today, we announced the public availability of the Microsoft WebMatrix Beta. This is an exciting time, as we’ve been working on this project for quite a while, and have been eager to get it out there! Our VP Scott Guthrie has been blogging about a number of its components in the last week or so, and you should definitely read through his posts to get a lot of information about it (start here).
In this post, I’d like to discuss how various pieces fit together, as I’ve seen some amount of confusion in the early user comments that I have read. Note that I’m not going to describe the pieces in much details (again, see ScottGu’s blog for this). Instead, my focus is on clarifying the relationship between some of the pieces.
Let’s start with WebMatrix. The term is actually used is two ways:
Key point: the WebMatrix tool is not by any mean the only way to create Web Pages apps. In fact, the Web Pages framework was designed to be very notepad friendly. On the other end of the tooling spectrum, it will later be fully supported by Visual Studio.
At its root, Razor is just a templating engine, which is best compared to something like T4. It is also comparable to the aspx and Spark engines. The best way to describe it in its most general sense is:
So as an example, you could envision a very simple command line tool that would read an input file and some parameters, and write out the result of running the template on that input. Note that everything I wrote here applies both to Razor and to something like T4.
Key point: Razor in itself is not tied to MVC nor to the Web Pages framework, and is not even really tied to web applications.
Note: check out Andrew Nurse’s blog for lots of technical details about Razor.
WebMatrix introduces ASP.NET Web Pages, which gives users a simple and powerful new way of writing ASP.NET apps. It is different from WebForms as it doesn’t use server controls. It is also different from MVC as it doesn’t follow the MVC pattern. Instead, it follows a much simpler ‘inline page’ model, where a page is basically an HTML page with some code added where needed. In that sense, it is reminiscent of Classic ASP, but it is also very different in the sense that it has the full power of the .NET framework available behind it. It also supports concepts like layout pages which make it much more flexible than the Classic ASP.
Where the discussion gets interesting is that the Web Pages framework uses Razor as its default templating engine. However, it is not tied to Razor. Potentially, you could use the aspx or Spark templating engines with the Web Pages framework. At this point, we have mostly focused on using Razor with it, but it’s entirely conceivable that other templating engines would be supported later.
Key point: ASP.NET Web Pages uses Razor by default, but is not technically tied to it.
ASP.NET MVC is not part of the WebMatrix release, as it is a completely different framework with different goals (and this post is not about the pros and cons of the two, so I won’t go into that here!). However, it ties into the story because the Razor templating engine will (soon) be made available as an MVC view engine. As it should now be clear, this does not imply that you would be using ASP.NET Web Pages if you choose to use Razor as your MVC view engine. All it means is that you’d be using the Razor syntax for your views instead of aspx (or Spark, …). This has no bearing on how you write your controllers or other parts of your app.
Key point: Razor syntax will soon be available as an MVC view engine alternative.
Hopefully, I have been able to clarify how some of the pieces that come with WebMatrix fit together. Please leave a comment if you have any questions and I’ll try to clarify further!