ASP: The Beauty of a Dead Language
First, let me preface by stating that ASP isn't truly a programming "language". Instead it's an environment, a framework, a set of tools which interfaces with other languages (primarily VBScript). But let's not be pedantic -- millions of people have been calling it a language for a decade...so, on with it then!
I am an advocate of ASP and VBScript -- not to diminish other technologies but instead because there is beauty in this programming environment which is still vibrant, powerful and complete. By "complete" I mean that it's finished - done - it's evolution has stopped and for better or worse (I think for the better) all of its greatness and all of its faults are forever static.
Some of this article may seem contradictory in and of itself. That's because I must meander between advocacy and eulogy. ASP is still powerful and useful but ultimately must be buried to make way for more robust technology.
Is ASP Really "Dead"?
Yes, but certainly not extinct.
From a purist's perspective, ASP has died. Microsoft stopped developing the environment shortly after they dove into the .NET framework. As a senior in college, I remember that my linguistics professor described Latin as a dead language and by that she meant that the language is no longer being developed; it's not growing or changing the way that, say, "English" or "Inuktitut" are still alive and evolving. Living languages are being rewritten and adjusted to accommodate new knowledge, technology, and art. Living languages are busy helping us understand "nuclear", "RSS", and "Ice Age". Latin and other dead languages make no allowance for such modern concepts and simply cannot respect our 21st century reality.
But Latin is also extinct - ASP is not. The difference is that ASP is still being "spoken" and is still a successful means of communication (with a web server, other server objects and services for example). A language becomes extinct when nobody speaks the language "natively" but I'd argue that there are still many programmers who feel right at home in the ASP environment. Clearly there's still a lot of great code to be written in ASP and VBScript before new generations of programming languages become a native tongue. Clearly ASP is still capable of delivering rich applications to gadgets and techno-devices and -- most importantly -- to web servers for many years to come.
This article then is really about enjoying ASP because it is dead. There's comfort to be found in its current static state. Read on...
ASP is Complete: Fini!
...but it's not time yet to put it to rest -- just the opposite. Instead we can enjoy that all of its strengths and limitations are known and it will never change. It's like an old friend: sometimes you'll get along and sometimes you don't but at least you'll know what to expect.
Does this mean that we shouldn't embrace the new and exciting? No. I'm simply suggesting that old wisdom has an edge that new knowledge lacks. Here's what my old wisdom suggests:
- ASP is not-so-good for these reasons:
When used with either VBScript or JScript, it's not a strongly-typed environment -- which unfortunately allows some programmers to build sloppy code and it's the author's responsibility to take special care of data-types and variables.
It's all "open source" (in the sense that the source code can be viewed easily in a text editor) which makes it impossible for authors to protect their creation from prying eyes.
In multi-lingual settings, there are fundamental flaws in the way VBScript's date and number functions behave. Perhaps the flaws that irk me are "by design" but nonetheless annoying. These flaws can be managed however with some ingenuity and care.
In multi-lingual settings, the "Response" object isn't always friendly -- but again this limitation is manageable and completely avoidable if operating on IIS 6.0 (Windows Server 2003).
And two features that are not possible with "pure ASP" and I think could have been remedied with the release of IIS 5.1 had Microsoft's focus not already shifted entirely to .NET: 1) there's no way to zip without a 3rd-party component and 2) there's no way to manipulate/resize photos without a 3rd-party component.
- ASP is good for these reasons:
It operates well on all Windows web servers since 1996. (And there's a surprising number of old servers out there still churning pages.) The last version of the ASP script engine (v3.0) was released coincidentally with Windows Server 2000 (IIS 5.0) and remains fundamentally unchanged since that time.
It's well documented with many forums, books, and web sites dedicated to the purpose.
There are many free script resources and tutorials available.
Experts abound.
It's capable of interfacing with old and new objects, components, services, etc. and continues to provide powerful server-side processing.
Commercially available WYSIWYG editors like Macromedia's Dreamweaver are equipped with ASP script libraries and extensions.
It's learning curve isn't intimidating. It's logic is still very approachable to newcomers and I'd argue still serves as a great introduction to server-side programming.
Its successor (ASP.NET) is maturing and gaining popularity at break-neck pace.
And best of all, and the reason I write this article, is that I am able to look at the ASP environment in its entirety -- from its beginning to its end -- all its history -- and make this list of things I do and do not like about it. There's no stress in wondering if the next version will fix the things I don't like; or if my current code will break on the next version web server. Instead there's a rather comfortable feeling knowing that it is what it is and always will be.
When's the Wake?
The future of ASP is no mystery...eventually everybody will lay it to rest and adopt .NET or its predecessor (or its competitor). The real question bothering die-hard ASP authors is "When and How Should I Migrate?"
Here's my best advice:
The .NET framework is already a couple of years old. If you haven't already migrated then there's likely a good reason and you should stay the course.
The best programming practices in object-oriented environments encourage authors to make clear distinction between the "business logic" and the "data" and the "presentation" -- this is more important now than ever. This means that you should strive to make your applications "modular" and build each layer with distinct purpose; there's usually a back-end where the data resides and there's a front-end which makes pretty pictures on the screen and in between is a middle-man which ferries information to and fro -- that's your ASP. Building these elements with distinction enables an author to alter any one of the individual parts without adversely effecting the other parts. When you are ready to embrace .NET (or anything else) it should be relatively easy to replace the ASP functions and subroutines without breaking the presentation or the data.
If you have a habit of writing "inline ASP", stop. Surely there's a way that you can wrap that code into a function or a subroutine. One of the great things, conceptually, you'll find working with ASP.NET and any of Microsoft's developer tools is that there's a page (usually an .aspx) and there's a "code-behind" file (usually .vb). The two can interact but their purposes are clearly defined -- one is "presentation" and the other is all business. This makes good sense and this practice should be applied as much as possible within the ASP environment.
You should migrate soon -- when you're ready. Enjoy your ASP as it's a great skill in your toolkit and it'll continue to be a powerful technology; but eventually you'll have to lay it to rest and learn new skills to stay competitive.
It's Legacy
Did ASP succeed? Yes...it's successor is ASP.NET. Had ASP not been effective, then Microsoft and other programmers would have abandoned it entirely. But they didn't. Instead the authors and developers of ASP built upon their wisdom and developed something more.
Is it still a viable option for programmers building new applications? Yes. As I build new applications for my clients I consider both ASP and ASP.NET to be rather equal (both strong but for different reasons). My choice really is whether I want to tell the client: "Yes...I'll build you that app and it will cost $x.00" or "Yes...I'll build that app for you but it might break when Microsoft releases the next version framework.". As the .NET framework is developed and revised the reasons to build applications in .NET become more compelling but, unfortunately, .NET won't enjoy the legacy that ASP does until...well...until it dies too!
Fossil Records
As I remember more about my linguistics professor, she enjoyed Latin for two reasons. The language can be studied as a complete unit and one can understand all of its rules (and all of its faults and exceptions). And in studying the evolution of languages, one can understand how it achieved and how it ultimately led or gave way to others.
At some point towards the death of a language, it becomes either incapable of meeting the needs of its "speakers" or its "speakers" adopt more effective ways to communicate which are fundamentally different than the previous. With ASP, I believe the causes of death are both of those. Ultimately it suffers a few problems which could not be mended or fixed without changing its fundamental framework and its "speakers" have grown to use other methods to communicate. And so...the environment was changed to resolve those few problems, ASP.NET was born, and "Classic ASP" will eventually fall towards extinction.
Regards,
D. S.