ASP.Net Post Mortem

I’ve spent the last few weeks driving around a Lexus for the first time, and I’m not exactly sure what to think about it.

On the one hand it’s very powerful, in the sense that it permits you to code your entire website as if it’s an application and not html.  Every page has a CodeBehind page that lets you work in the exact same way that you would on a desktop application.  And the HTML side of the page barely needs any HTML at all.  In fact, you can get away by using ASP.Net controls almost exclusively, including for such simple things as links and images.  And those controls, by default, will just post back to your codebehind page, just like wiring up events on a GUI form.

I can see why ASP.Net developers like it.

On the other hand, it completely ignores all established web development conventions. The very things that make it nice for a lot of developers are what make it a poor fit for web development if you use it in the default fashion.  Many of the things which make ASP.Net convenient fly in the face of the way you’d do development on any other platform.  To many, I’m sure that’s a good thing.  It’s easier to set up an ASP.Net control, set runat=”server” and just catch the OnClick event in the Codebehind and do your thing than it is to learn how to set up an HTML form and learn to set the form’s Target, give it a submit button and make sure whatever page is the target has code to catch a form submission but do something different when it’s just being hit directly.  I get that.

But the way handles a lot of this just outright breaks things that would be otherwise simple.  First, a primer. controls are, in essence, pieces of .Net code that get rendered by the server at page load and turned into html at that time.  So while your page may have an ASP:LinkButton for your link, when it gets sent to the broswer it’s a straight link tag.

But let’s say that LinkButton has an ID that you want to reference through Javascript on the page, and that ID is “submitLink.”  You build your Javascript to reference “submitLink” only to have it error out because no control with that ID exists.  Huh?

Turns out when ASP.Net renders your Linkbutton into an html link it also changes the ID, so now what you’ve got is “ct100_LinkButton_submitLink.”  But you have no way of knowing what that ID is going to be until you load the page and look at the page source.  So if you want to do any Javascript or CSS that references control IDs, you have to load it in a browser and rip the IDs out of that.  What concerns me further about that is, if the ID is generated dynamically, how can I be sure some change to the code won’t screw the ID up and break my Javascript?  So far, I haven’t found an answer to that question.  If there isn’t one, that’s a bigger problem than just an inconvenience.

Now, you can use regular HTML with ASP.Net and create rational webpages with it.  It’s not a broken platform, exactly.  The problem is that because these Desktop App style crutches exist, people use them when they shouldn’t.  The site I worked on is filled with ASPisms that, on reflection, bother me a lot. Pressed for time and lacking experience, I fell back on those crutches because they were the closest tool that could get the job done.  I think one day I’m going to pay for those choices.

ASP.Net feels like a web development platform designed specifically for the Visual Basic coders of the 90’s.  People who have a low tolerance for new ways of doing things and little interest or ability to step outside of their comfort zone.  It’s web development for non-web developers.  It lets you build a desktop application that shows up in someone’s browser.  At least, its default configuration is.

What that default configuration leads to is a lot of programming that works fine in desktop applications but is clunky and slow over a network.  ASP.Net promotes inefficient web code by allowing you to work within parameters that aren’t optimal for the web, and giving you all the tools you need to stay there forever.  We have an internal website which is terrifyingly slow for what little most clicks do, and most of it can be tracked back to ASP.Net letting our developers build it as if it were a desktop application.

You could do some excellent work in ASP.Net, but I believe that by doing so you are probably avoiding many of the things that were the reason you chose it in the first place.  I could avoid using ASP.Net controls and do things in a more purely HTML way, but that’s just breaking the paradigm Microsoft set up.  If I’m going to do that, I’ll use a platform that was built to integrate with HTML more naturally.

I understand the world ASP.Net is meant to live in.  I just don’t like it all that much.

This entry was posted in Coding. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *