This post started out its life as a scathing rant after spending way too many hours chasing after a very silly bug (which I still didn't fix, and have no idea how to). I spoke with a friend about it, and he managed to put me in perspective, so this should be a more balanced post.

It's about ASP.Net and the model that it gives the developers who develop with it. Let's go re-iterate a few well known facts here:

• The Web is stateless.
• Humans are not.

Those simple facts are the basic reason that we've a complex architecture for ASP.Net. It attempts to bring state into the web. It mainly does so with ViewState and a few other tricks.  One of the things that ASP.Net does very well is to give you a framework where you can build web sites very easily, by using self contained components that present a very nice interface to the developer, and a nice UI for the users.

The declerative approach allows ASP.Net to get rid of a lot of needless code (at the expense of increased compile times). I really like some of the stuff that I can do there. And 3rd party components can save you weeks or months of programming. For the most part, it works quite well. There are some problems with it, of course, view state bloat is a common one, but it is the less serious one.

The more serious problem is that you no longer work on the web. You are working on ASP.Net, and the web is abstracted away from you. And you know, if it was a 99% proof abstraction, I would love it. But it's not. It can't be. So I get into problems that I can't get out of because ASP.Net tries to do clever stuff behind my back.

A recent problem that I had was with a control getting the value of another contorl. The issue turned out to be an optimization for the ASP.Net engine, where viewstate seeks where done via indexes, and my controller was at the wrong index, at the wrong time. There is a (simple) solution for this problem, but finding out what the problem was took me over a day.

To be fair, most of the issues I'm running into seems to be on the edges of what should be happening (loading a dynamic control defined in a page from the master page, if the control has initial values, it ignores all other posts and maintain its initial values). This doesn't comport me very much, since I do not walk the straight and narrow. Not often, at least. Nor do I intend to. It's incredibly frustrating to see the problem, to know what is wrong, but to be unable to find out why.

A lot of the design choices made for ASP.Net make it much easier to develop for the web without needing to think about form variables, and query strings and cookies and all the rest of the fluff that interrupt our work when we want to add some business value (or just a cool feature) to an application.

I literally can't remember the time when I run into an HTTP level bug. In any platform, in any environment. The rules are very simple, and you need to do a lot by yourself. I like that. I can control everything from the HTTP stack upward. But this force me to handle variables myself, and to keep state between request, and to handle a lot of stuff that is simply time consuming and not really productive. At the end, I'll probably roll my own version of maintaining state between request. And I'm pretty sure that it, too, will be based on a hidden field.

But rolling my own means that I can go there and figure out what is wrong. I'm a member in the Castle Project, and that means that I am familiar with MonoRail on intimate level. MonoRail doesn't offer a state management out of the box, nor does it offer a rich toolbox full of ready-made components that you can use to create rich UIs by merely dropping item into the designer surface.

I'm going to completely ignore the design and maintainbility benefits of using MonoRail, and concentrate on a totally different aspects of it. First, it's keep me very close to the stateless model of the web. Which mean that I'm not deluding myself thinking that I can build winforms applications for the web. It means that nothing much is going on that I can't predict. There is a lot of magic in MonoRail, make no mistake. But it's a magic that is carefully trimmed to make sure it doesn't evolve into the Evil Witch of the West. The second part is that I have the source (and so can you). If something is going on that I don't understand, I can dig in and find it.

Problems like the ones that have been chasing me for the last few weeks would simply go away if I used MonoRail, since I would be able to control everything from the top down. But this control come with a cost. For instance, Infragistics has some nice looking controls, which I couldn't use if I used MonoRail*. If I wanted similar functionality, I would've to write it myself.

My thoughts on that? So what? I'm not going to implement each and every features of a pack such as Infragistics. MonoRail has some really nice ways to package common functionality. How long will it take to implement a basic grid, for instance (which MonoRail already has, btw). I mean, seriously, how hard it is to spit out an HTML table? Oh, you want in place editing? That isn't that hard either.

Yes, for the first application that I would write, I may need to write components that already exists for ASP.Net, but web components are usually simple. And when they are not simple, they are specialized. One of the reasons that ASP.Net components can be complex is that they try to be both simple and extensible and the same time, and sometimes it just breaks. They are either simple or extensible. Sometimes they are neither. For the second application (or after a couple of weeks have passed with the first one)? I already have those components. I can write the HTML to display just about anything you can imagine. And from there it's a simple matter to create a reusable MonoRail component.

To wrap things up, I think that it's pretty obvious where my stance is. The time that is saved using ASP.Net productivity features isn't higher than when using MonoRail. In fact, I would argue that it's the other way around. Certainly such problems as I've run into** recently caused me to lose time rather than gain it. You've to realize that I signed today and wished to be programming in VBScript using ASP 3.0, because at least then there was nothing much between me and what was happening. This is how frustrated I've became.

One thing that I liked in both MonoRail and ASP.Net is the level of support that I can get. In MonoRail I can talk to the people who wrote the code that is giving me trouble. In ASP.Net, I can (usually) do the same***.

Note: I purposefully left Ajax out of the picture, I'm not using Ajax in my current project, so I don't want to talk about things that I don't know.

*I'm pretty sure that this is a point in favor of MonoRail, but that is just in the case of Infragistics.

**Yes, I realize that at least in part it comes from not being completely knowledgable about ASP.Net 2.0.

***And Microsoft has been very helpful. I expect to get a response from them in the morning, probably a three line answer that explains what is wrong and how to fix it****.

**** I also expect to feel like an idiot in the morning. ("Oh, so that was what was causing it?)