Too strong? Maybe, but the ASP.NET Web Forms programming model has run its course. It was hugely impressive when it originally appeared - I remember it being announced as ASP+ in 2000, and how phenomenal it seemed. You can build a web page visually, using a rich set of controls, and have ASP.NET abstract away much of the problem of managing state. It also lets you write code in any .NET language, which is just-in-time compiled at runtime for fast performance.
ASP.NET works the same as ever today; but the web has moved on. The Web Forms model makes programming the web more like programming Windows, which was cool at the time but not any longer.
Fortunately for Microsoft, it has an alternative, called ASP.NET MVC. The first full release was announced at the Mix09 conference last week, and you can download it now. I took the opportunity to ask some of the delegates what they thought of it.
The reactions I got fell into two broad categories. The first group found it difficult to puzzle out what it really was, even those who had attended sessions on the subject. The second group loved it, and never ever wanted to go near Web Forms again. In fact, such was the frustration with Web Forms among some developers, that they had developed their own alternative frameworks but were now moving to the official one.
So what's wrong with Web Forms? Complaints I heard include that it is not testable; that it is not really compatible with AJAX; that it is inflexible; that ViewState, hidden form data which preserves state across page refreshes, is a nuisance; and that it is hard to write REST-style applications or those which properly support the Back button.
Enter ASP.NET MVC, which answers all of these complaints. MVC stands for Model View Controller, though having played with it a little I find the name somewhat misleading, as well as being a mouthful (contrast the delightfully-named MonoRail, which is an interesting alternative). Why misleading? Well, it doesn't have much of a Model, as this post observes. It does have views and controllers; but I think one of the reasons developers find it hard to grok is that starting with a discussion about MVC architecture is not the best way to teach it.
I think the place to start is with URLs and routing. It also helps to know that ASP.NET MVC follows the principle of convention over configuration (though not to the same extent as Ruby on Rails). In a nutshell, ASP.NET MVC breaks the link between the URL in the browser and aspx files on the web server; instead, it processes the URL and returns what you want it to return.
A "View" in ASP.NET MVC is an .aspx page, but in the form of a lightweight template, not a Web Forms with a complex page lifecycle.
I've been playing with ASP.NET MVC recently, and it is a delight. Yes, there is more manual coding than with Web Forms, but it is worth it for the additional control you gain. Even the performance seems better, a consequence of the lightweight approach. As it happens, I'm also a believer in test-driven development. I guess I'm in the second group that I spoke to at Mix09.
Microsoft is not killing off Web Forms; rather, it is very insistent that they remain under full development. I get the impression that the company expects ASP.NET MVC to be a minority choice.
Nevertheless, if you work with ASP.NET do not hesitate to check out the new framework. Personally I think ASP.NET MVC might just rescue its web platform from a slow but inevitable decline.
I'm at Microsoft's Mix09 conference in Las Vegas, where the big news (aside from small matters like the final release of Internet Explorer 8) is the beta release of Silverlight 3.0, Microsoft's browser plug-in that competes with Flash as a platform for rich internet applications.
Silverlight 3.0 is stuffed with new features, one of which is the ability to run outside the browser. Right-click an applet, choose Install onto this computer, and suddenly you have a desktop application complete with a shortcut in the Start menu, or on the Mac desktop. This has triggered a debate over how SLOOB (that's Silverlight Out Of Browser) compares to Adobe's existing AIR (Adobe Integrated Runtime), which supports Flash applications running on the desktop.
Understandably, Adobe folk like Ryan Stewart are emphasising the differences:
"I think AIR and the Silverlight OOB (Out of Browser) are two very different technologies for two very different scenarios...AIR is about letting you take your web application skills to build desktop applications and Silverlight OOB is more about letting you take your Silverlight applications to the desktop. The different models will be different for everyone, but right now AIR gives you a lot more flexibility and more API hooks into the operating system."
The big issue is how much these desktop/web hybrids interact with the local machine. Microsoft makes a point of how SLOOBs run in the same sandbox as they would in the browser, which means the user can install without a security prompt, but also that the application has very access to the user's desktop. The only access to the file system is to a protected area called isolated storage, or via a file dialog that the user controls. Microsoft says there might (or might not) be a way of displaying notifications but that is about it.
AIR applications by contrast run with the same permissions as the user. Installation involves the user consenting to a dialog which usually threatens unrestricted access to the system. Your AIR app can read and write any files that the user can read or write. There is also a notification API, and support for drag-and-drop.
That said, AIR applications are also restricted by design. They cannot be extended with native code, or execute other applications. Adobe has always presented AIR as a way of delivering web applications on the desktop, rather than as an alternative to C++ or .NET for traditional desktop applications. So is it really so different from SLOOB?
Well, some of the AIR features do give it an edge. One is the ability to fire notifications (annoying though this can be). It's something that Microsoft definitely intends to add to SLOOBs, though I get a different answer every time I ask about it; it might not come until Silverlight 4.0. Another difference is that AIR can host HTML as well as Flash content, which is an advantage for applications that depend on both. AIR also includes an embedded relational database engine, SQLite, whereas SLOOB developers will have to roll their own or use XML, though I doubt this is really a big deal. One other thing: Silverlight knows nothing about printing, which is unfortunate when running outside the browser.
Nice features; but I still feel that AIR and SLOOB are close competitors. Both take a cross-platform, rich internet application runtime and make it available from a desktop shortcut and with offline support. That makes a huge difference to users, even if the technical differences between running in or outside the browser are not so great. SLOOBs are going to be attractive to .NET developers because they include the .NET runtime and can be developed in the familiar Visual Studio IDE.
Personally I'd like to see an option to run AIR applications sandboxed, as full file access is more than most of them need. I'd also like an option to run SLOOBs with greater local system access when needed. Why not have the best of both worlds?
In the meantime, I'm expecting both to succeed. For applications that will work as a SLOOB, it makes a great user-friendly, cross-platform alternative to Windows Forms; and we've already seen effective user of AIR for cloud-centric utilities like Twitter clients. Both platforms are also highly effective for visualizing data. Who knows, this approach could become the norm for a wide range of business applications.
Historically, the web development choice between the Microsoft platform and open source has been a fork in the road with many consequences. Choose Microsoft, and you generally use Visual Studio, Internet Information Server, ASP.NET, C# or Visual Basic, and SQL Server for the database manager. Choose open source, and you most likely target LAMP in one of its guises, the most common being Linux, Apache, MySQL and PHP, and work in Eclipse or almost anything other than Visual Studio.
Recently the boundaries have been blurring a little. Apache actually runs nicely on Windows, and I've used it happily to host a Subversion repository, while on the other side Microsoft has been making an effort to support PHP in IIS 7.0. But what about running ASP.NET on Linux, is that a silly idea?
I've been following the efforts of the Mono project in this area for some time, though it's been a while since I've tried it out. Mono was originally focused more on desktop than web applications, and I've used it mostly in that context. When laterooms.com tried Mono in early 2006 it quickly gave up, citing problems with Mono's Boehm garbage collector; see the developer's comments to my blog post at the time.
Still, that was three years ago. I had another look a couple of weeks ago, and I've been impressed. In particular, the ability to develop in Visual Studio and deploy to Linux is interesting. I'm working on a small project, and getting this working is remarkably simple. I used Visual Studio 2008, but set the project to target .NET Framework 2.0, as Mono lags behind Microsoft in implementing the latest .NET APIs, and using MySQL rather than SQL Server, since this is available on my Linux web server. Using MySQL with .NET is straightforward thanks to the official ADO.Net provider, which specifically supports Mono as well as Microsoft .NET.
On the web server, running Debian 5.0 Linux (Lenny), I installed the libapache2-mod-mono and mono-apache-server2 packages using Aptitude. Next, I configured Apache to use Mono on a particular web site, with a few lines of manual configuration, as explained here, and imported the MySQL database from the Windows development machine to the Linux web server.
Back in Visual Studio, I compiled the web site, uploaded it, and it worked first try. Performance is good as well.
I realise that a number of caveats apply. It's worth reading this page, the current Mono todo list, which notes some of the important areas where Mono is lacking and includes the comment:
Mono is known to be not as performant as the .NET Framework.
Note that Mono still uses the Boehm garbage collector, though an alternative is in development. Further, Mono does not implement the entire .NET Framework. Mono is a brave choice; Windows and IIS the sensible option for .NET applications.
It still seems to me significant that you can easily deploy to Linux and Apache using Mono. Not all applications are mission-critical, and not all applications need to scale as well as Laterooms.com. Mono has a number of attractions. First, it is open source, so in the event of problems you can always obtain and amend the source code. Second, running on Apache and Linux is a considerable saving in license costs. Third, you can get official developer support from Novell.
Why would you use C# and ASP.NET rather than PHP or Java? The main reason would be because you know and like the language, the platform, and/or the Visual Studio IDE. In an interesting report on the state of the computer book market, O'Reilly notes that C# is now the largest programming language for all book sales. Thanks to Mono, you can use C# but still deploy to an open source platform.
It also seems to me that Microsoft's official support for Moonlight, the Mono implementation of Silverlight, is important. Microsoft now needs Mono, in order to tick the cross-platform box and compete with Flash, giving more assurance to its long-term future.
Mono's growth over nearly a decade has been slow but steady. Perhaps now is the moment that it creeps into the mainstream.
Are you using Mono, for web or desktop development? I'd be interested in your comments.