About four years ago, I wrote a little CMS with support for plugins and a number of other neat features. I continued to work on it off and on until I went to work for Fog Creek. Since then, it has languished in a Subversion repository on my hard disk. I don't have any desire to resurrect it, so the repository will probably get converted to Mercurial and then languish for another four years.

At the time, I spent a lot of time figuring out how APS.NET ticks. It is really a remarkable system. Originally, it was designed to allow Visual Basic programmers to transition to writing web apps without having to learn much about web programming. Yet for all its power and cleverness, is just plain fails. It failed in 2001 and fails even harder now.

The idea that you can shield web developers from having to get into the nitty-gritty and learn HTML is just cuckoo. HTML is the minimum any web developer should know, and in today's web, they should also know JS and how to use jQuery or a similar JavaScript framework. While ASP.NET tries to save you from doing that, its abstractions leak so badly that all the boys in Holland couldn't plug all the holes. Even if it did, despite its powerful control library, ASP.NET does not make it easy to do something it was not specifically designed for--and it was designed pretty narrowly.

Let's look at what happens when you, a neophyte web developer, first encounter ASP.NET. If you only use the controls provided in System.Web.dll, and write all of your own controls using the UserControl abstraction and learn HTML, you can create a half-decent web app using little more than your existing VB knowledge. That is, until you create a page that has a lot of cool stuff on it, at which point your 20K page turns out to weigh in at well over 500K. After a little research, you will find the culprit turns out to be ASP.NET ViewState. So you turn it off and your page is tiny again, but now none of you controls remember their values when buttons are clicked. You do some more research and learn that each control stores is value in ViewState to pass data across page loads, so you go through and determine whether you should enable or disable ViewState for each control. When you're done, even if you have something that mostly works, you have a big page instead of a huge page--and the abstractions designed to save you from learning about the web have merely forced you to learn the arcana of how ASP.NET tries and fails to hide the web, instead of writing a well-written web application from the beginning.

The remaining source of hugeness turns out to be a list control that you databound to a giant list of things from the database. The database can give you paged data, but the list control doesn't really like to be given anything but the full list--even if the control only shows a subset. At this point, you can either dig into the inner workings of the list control and try to trick it into doing what you want, or you can write your own list control. Either way you have a ton of work ahead of you.

The basic problem is that ASP.NET is not built on top of a windowing framework, but it tries its hardest to act like Windows Forms. So the abstraction breaks down whenever you run across the two big differences between web development and windows development: state management and how to display your controls--or in other words, basically the whole thing.

In an AJAX world, ASP.NET is even worse, because the idea of rendering only part of the page just does not map well into ASP.NET. Microsoft has an AJAX library that is built around the concept of an update panel control, which allows you to specify a chunk of the page that can be replaced via AJAX. This works for small things, but before too long, you put almost all of your page inside update panels. The end result is that each time you need do an AJAX request, almost the entire page is sent to the client and replaced via JavaScript, so even if only one control needs to be rerendered and replaced, all of them are.

ASP.NET MVC which throws away most of the ASP.NET infrastructure and builds up an MVC framework on top of the IHttpHandler interface (the lowest level part of ASP.NET). The MVC design pattern as applied to web design is inherently stateless, so even though the programmer is forced to actually think about state management, he writes cleaner, shorter code. The other thing it does right is to provide a set of extension methods that encourage the programmer to generate a bunch of html strings instead of an tree of controls.

In my experience, a good VB developer should have no problem learning to write good web apps, even ones that do neat AJAX tricks. Unfortunately, ASP.NET tends to prevent those programmers from being successful rather than help them.