ASP.NET’s killer features are already here

ASP.NET is definitely an interesting beast. It’s open-source, developed in the open, and the team has clearly studied the competition, Node.js in particular, very closely. Its killer features, however, the ones that may be hardest to reproduce by others, are not new features: we already have them.

Modern web frameworks are lean, composable, low-level, and asynchronous. ASP.NET MVC is not there yet, especially on the lean aspect, but it’s definitely getting there if the progress so far is any indication, and it is. If it was only getting as good as Node, however, it wouldn’t be enough to make it successful. It needs to be a notch better in order to convince current users of other frameworks, and to overcome the perception in most startups that Microsoft has become irrelevant.

The first feature, that I think makes superior, is a feature of C# that we’ve had for a couple of versions: async/await. Asynchronous programming can be tedious and difficult, and JavaScript doesn’t do an outstanding job expressing it. Its reliance on callbacks, even with the help of libraries such as async, make it noisy and quite tricky. Async and await make asynchronous flows look linear, very close in fact to their synchronous equivalents. That makes it more approachable, and easier for beginners. That advantage, however, may not last for very long, as JavaScript is getting async/await in version 6.

The second feature is going to be a lot harder to reproduce, because it’s only really made possible by C# being a strongly-typed language, and we’ve enjoyed it since the first version of ASP.NET MVC: model binding. Being able to just write an action method, and have form data automatically mapped to the method’s parameters, is an awesome productivity boost, and makes the code much more expressive. This can’t be reproduced in a dynamic language without specifying a lot of extra information that is ambient and already there in the case of C#.

If ASP.NET MVC succeeds in emulating what makes its competition compelling today, these two advantages would put it a step ahead, and maybe even the best choice for a web framework. Interesting times…


  • I agree that model binding is fantastic. It really is what makes ASP.Net MVC great. It's really only necessary in a typed language, though. In any Node web application the request body is already an object - whether it's submitted as JSON, a form POST, etc., thanks to middleware or plugins (which is essentially how ASP.Net does it). I maintain and develop ASP.Net MVC/WebAPI applications as well as Node applications and I feel just a little more productive in Node. For me async/await in C# is the big win for .Net. Libraries like co make async a little nicer in JS but it's still a ways off before easy async programming is mainstream.

  • @Matthew: you make a good point about JSON payloads. That does not cover the case of HTML POSTs however. Mapping form fields to method parameters, and generating form field names so that they will be correctly interpreted by model binding, is something that's really useful if you're building web applications that are not built as SPAs.

  • How is this no-compile experience different than the existing Web Site project within Visual Studio? Is Visual Studio not going to produce DLLs by default, even for web application projects?

  • @ravi: I don't know the details on that, but it is my understanding that the new Roslyn compilation infrastructure brings quite a lot of improvements in terms of number of assemblies generated, and first hit performance. You'd have to ask someone on the team for the specific details however.

  • @ravi: The way it was explained to me, which took me a few minutes to fully grok, is that vNext/Roslyn is so fast that it's actually faster to always [re]compile a site's source than it is to search for cached assemblies (DLLs) in several locations on an SSD. That's pretty darn quick. So, that's why it doesn't need to produce assemblies/DLLs anymore.

Comments have been disabled for this content.