A Look Back at ASP

A Look Back at ASP

ASP is a powerful model and is the right tool for most jobs. The information systems department I manage has written and has running more than 100 ASP pages that clients (internal and external) use to access various pieces of functionality within our organization. But if you've had the chance to work with ASP, you know that it has some drawbacks. You know that you have to write code to perform any operation, and you quickly notice that you are dealing with spaghetti code. The unstructured nature of ASP code—where everything is placed in an ASP page—often offends purists. Yes, you can use include statements, but doing that requires more work. You usually find ASP logic script code mixed with HTML tags for presentation. This mix, of course, does not help readability or debugging, and because ASP uses interpreted script, performance problems arise in some cases. But in spite of the difficulties, ASP has evolved to become the foremost tool in the Windows-oriented Web programmer's toolbox.

One thing that always bites Web developers is the need for multiple browser support. When we design ASP pages for external clients, we must either program to the lowest common denominator of browser or write extra classes to support each browser the clients might use. Not only that, but no state management is available unless the programmer writes acres of code to persist values from page to page. Of course, ASP has the Application and Session objects, but there are two potential problems with these. First, they make scaling a high-volume site difficult. Second, because they are run on the server, if the host has a server farm, you can't be sure that the next page won't be served from a completely different machine. Luckily, ASP.NET solves these thorny problems.