After thirteen years of web development, in which the last five I spent almost entirely developing with the .NET platform, I finally saw in Classic ASP the most versatile environment for web development. The main reason for this versatility is, surprisingly, the fact that it is interpreted. It might sound like a joke, mainly because of the whole buzz around the code-behind and the advantages of the compiled code's performance. But, in my opinion, this attribute, summed to multiple languages support, is what guarantees to ASP a distinguish position among the environments for advanced programmers.

Aiming to share my experience and point of view to the whole community, I've decided to create a series of articles, where I'll address key topics that will lead to a greater understanding of the strength hidden in ASP. I've ordered them so that easier topics are discussed first before moving on to the harder ones. Here they are:

  1. ASP, a misinterpreted technology
  2. Event-Driven-Programming and lambda function in ASP/VBScript.
  3. TDD (Test Driven Development) in ASP/VBScript.
  4. Languages: Based on Objects and Object Oriented.
  5. Object Oriented in ASP/VBScript "Hackers way".
  6. "Scripting Components", the ace in the role.
  7. Caching: the concept of DRY (Don't Repeat Yourself) applied to ASP.

In all subsequent articles, I'll indicate the current stage in bold. I don't intend to stop contributing after the end of the seven subjects. I'll probably attack more problems and more specific topics that illustrate the advantage of using ASP. Well, one step at a time...

ASP is not just coded in VBScript

Generally, because we so often say "programming in ASP", many people think that ASP is a programming language. This also happens with .NET, despite all the marketing and community effort to clarify the matter, there are still a lot of people who don't clearly understand the difference between a framework and a programming language. These people are programmers and non-programmers. Of course we accept the fact that non-programmers do not know this difference, but it's unacceptable that programmers can't distinguish one from the other. Microsoft did a good job in advertising .NET so that programmers are sufficiently well informed on the matter (it's quite normal to see people correcting others in forums). However, in the Classic ASP area, it's very common, for example, to find analysis such as "PHP vs. ASP" and no one claiming about it. The height of absurdity is when people compare the syntax of PHP with the syntax of ASP/VBScript and judge PHP as superior to ASP, just because the PHP is a member of the C/C ++ family, which has a broad base of programmers that, supposedly, would learn the language faster, because of the similarity of the syntax. This is due to the fact that the authors are required to choose a language to be able to say something about ASP. I contribute, in some way, to this confusion, since I wrote the specification of the "ASP language" in the GTKSourceView-2.0 using only the information of ASP/ VBScript. That's right, every new geek that opens a program based on GTKSourceView-2.0 in Linux and choose the ASP option, will be using a ASP/VBScript specification. Therefore I accept the convention that, in the context of the language the ASP is implicitly understood as ASP / VBScript.

The fact is that ASP is the precursor of CLI (Common Language Infrastructure), an open specification created by Microsoft that defines the executable code and the execution environment that form the core of several company's products (including .Net Framework, Mono and Portable.NET). Therefore, it supports many programming languages, for example: VBScript, JScript (official), Perl, Python, TCL (thanks ActiveState team) and even, for your surprise again, PHP (thanks Wez Furlong) and Ruby (thanks Arton). Finally, any language with an interface to the ActiveScripting of Windows works for programming in ASP. As an example, follows the code below that goes to my server:

<% @language="VBScript" %>

Response.write("Running ASP(Active Server Pages) with VBScript" & vbNewline)
Response.write(python() & vbNewline)
Response.write(ruby() & vbNewline)
Response.write(js() & vbNewline)
Response.write(perl() & vbNewline)
Response.write(php() & vbNewline)

<script runat="server" language="Python">
def python():
    # Response.write("Running ASP(Active Server Pages) with Python.")
    return "Running ASP(Active Server Pages) with Python."
<script runat="server" language="RubyScript">
def ruby()
    # Response.write("Running ASP(Active Server Pages) with RubyScript.")
    "Running ASP(Active Server Pages) with RubyScript."
<script runat="server" language="Javascript">
function js() {
    // Response.write("Running ASP(Active Server Pages) with JavaScript");
    return "Running ASP(Active Server Pages) with JavaScript";
<script runat="server" language="PerlScript">
sub perl {
    # $Response->write("Running ASP(Active Server Pages) with Perl.");
    return "Running ASP(Active Server Pages) with Perl.";
<script runat="server" language="PHPScript">
function php() {
    // $Response->write("Running ASP(Active Server Pages) with PHP.");
    return "Running ASP(Active Server Pages) with PHP.";

This kind of behavior exponentially increases the power of ASP. A multilingual interpreter like this has the power to understand expressions that couldn't be generated quickly using only one language, or that couldn't even exist in other languages.

ASP is a technology that works

This is another big misunderstanding that exists about ASP. Many believe that Microsoft created the .NET framework due to the fact that ASP hadn't worked out. People say that compiled code and hard typing are better, and so on. I think that Microsoft created the .NET just because the fact that ASP worked out! At least through the web, it did! I remember thinking many times in my beginning of .NET: "This library doesn't work exactly the way I need to access the database, what it wants is that I get the data-source and attach it right to the grid, which doesn't have the features I need! Damn language, it seems that they did first the objects and then made the libraries just to cover the needs of the objects they created". A year later, version 2.0 .NET was released, which broke compatibility and improved a little the situation of ASP.NET. What really happened is that I, like many other professionals in the ASP area, was bombarded with powerful marketing from Microsoft and thought that the future was in .NET. When all that .NET provided as differential, was already in ASP, but in a Java form... or you thought that was a coincidence that Microsoft "cloned" Java (J#) and made a bit modified proprietary version of it (C#) to be the head language of .NET?

For those who still have doubts, take a look ASP Conventions (topic ASP Application Directory Structure), written in March 17th 1998 by MSDN. Notice the directories /Classes and /DLL, that Microsoft itself declares being useful for, respectively: "Holds Java classes used by the application" and "Should contain COM server components and Visual Basic 5.0 run-time DLLs". Does anybody still doesn't get that the Classic ASP was already structured to work with compiled code since 1998? Just the fact that ASP runs Java classes natively without the need of server registration should be an enough hint.

ASP hasn't stop in time

As you should have noticed, despite the official languages (VBScript e JScript) of ASP do not have a large library, other languages such as Python, Ruby, Perl and PHP bring their entire built-in library ready to be used in ASP, which means that ASP is still evolving and getting better as the other languages grows and get mature. And more, the new ADO, XML and other components created for the .NET, are also available for the Classic ASP, that's why we're able to call the MSXML2.DOMDocument60, for example.