Something Smells

ASP.Net Frustration

It's very hard to articulate "why" I am frustrated with ASP.Net. Recently, I found a post that, while not articulating the "why", does articulate the feeling:

I think what annoys me the most is that I really like C#. It’s a great language, and the .Net framework is awfully well put-together. I really enjoy spending time with C#, but then along comes ASP.Net like the loud, overbearing, half-drunk uncle at a family reunion, tips over our picnic basket, and ruins everything. - Deane

I've tried exploring this subject on many occasions and come to the conclusion that it is a subject best discussed over a pitcher of beer! Before I go on I must give thanks to the guys (and gals?) at the castle project and their incredible Rails Framework Monorail.

So, ASP.Net is frustrating. To be fair to many who have bought into ASP.Net, ASP.Net sells itself very well. As a technology it is very heavily driven by marketing needs. The MS sales force wanted a technology that "sells"...and they got it. Viewstate, seemless event handling, Components, a response and request pipeline that can be "easily" hooked, and many more features make it a must have technology!

Wow, why the frustration? I think until you've tried something better (see rails above) you just accept the frustration. Heck, it's still better than the procedural approach of ASP or PHP...right?

The easy answer is "developers should know more about the http process and ASP.Net hide too much." That's always sounded a little like a cop-out to me. Don't get me wrong...I agree with the basic premise but I don't think it's the framework's problem. I see a real usability problem with ASP.Net.

ASP.Net wants to hide the ugly details of maintaining the viewstate between the web browser and the server code. The idea is great but in practice it seems to be heavily dependent on the IDE. Webforms seems to give us great options for seperating the UI from the logic. In practice though it gets a little hairy.

Where I work, we often put together "Scafolding" views that are meant to be thrown away or refactored once we've got everything working on the back-end. The Webforms designer in VS.Net allows you to create "Scafolding" very quickly....but when it's time to refactor, the code is difficult to un-hitch from the IDE.

Another problem with the Webforms approach is how verbose the ASPX code becomes! Unless you do everything in the Designer (which isn't much) you often need to drop into the code. Looking behind an ASP.Net page or into the hidden regions is like opening a pandora's box of problems!

Finally, why does the page event pipeline need to be SOOOO complicated! When we were using WebForms I would often override the whole thing just to get a little control back! The Framework should make it easier to munge with the request/response pipelines but in many ways Webforms makes it harder.

OK...you've wasted another perfectly good 10 minutes reading my rant. As usual I welcome the wisdom of others in all matters about which I write.