Initially released with Microsoft Internet Information Services (IIS) late last century, Classic ASP hasn’t seen an update to its functionality since ASP 3.0 in 2000. Used on website and web applications typically written in VBScript, Classic ASP somehow seems to keep on going even in the face of competition from better, more modern website development platforms like ASP.NET, PHP, Java Servlets and JSP, Ruby on Rails, … the list goes on. In many cases it can be harder to achieve something in ASP than in a more modern development platform.

So why won’t it die?

Well, in most cases, websites and web applications stick with Classic ASP because of either cost or risk. When you have a large codebase written in Classic ASP, it can be quite challenging to migrate it to another platform — and essentially requires a rewrite.

Depending on the functionality, that might mean a lot of money. Sure, in some cases you could just drop in a CMS like WordPress, Joomla! or SharePoint, but often there is specific functionality that needs to be reimplemented in the new platform.

When that functionality entails some complexity, there is risk that the reimplementation doesn’t meet requirements any more. Choosing to upgrade to another platform just so that one or two new features can be added can mean the difference between delivering new features on time or missing opportunities while bugs in the recode are sorted out.

The tangled way in which Classic ASP websites and applications have often been developed can make it difficult to work out just what they do, and what the business rules are. And of course, typically no documentation!

All of this means that Classic ASP websites are not all going to go away any day soon.

Life support

A Classic ASP website can keep going for as long as Microsoft keeps issuing security patches. It continues to be supported on new Microsoft Windows server products, and the installed codebase in corporate intranets means that it is likely to receive support for a while yet.

The single biggest challenge to supporting an old Classic ASP codebase is security. I often see lots of code written with little regard for security, opening up the possibilities for hacking the website via SQL injection or XSS. It’s easy to write good new code that is secure, but making old code secure can take a lot of effort. Thanks to the automated hacking tools available now, programmed to seek out and violate vulnerable websites, it is imperative that site security is addressed properly.

Renewel

Adding new functionality to a Classic ASP website can be a little challenging: typically the code is all VBScript, and that language quite simply doesn’t make it easy to achieve some tasks. Additionally, the coding style of Classic ASP circa 1998 was truly atrocious — a tangled mess of HTML code interspersed with bits and pieces of VBScript, sometimes generating more tangled JavaScript. However, that shouldn’t stop the resourceful programmer, because there are options:

Classes

Basic object-oriented methods can be applied to make VBScript code easier to maintain. Sure, VBScript’s classes are fairly simple things with no concept of inheritance or interface implementation (even VB6 could do interfaces!), but with encapsulation, properties, and Private / Public, you can still achieve quite a lot. And because VBScript doesn’t use static typing, you can simulate polymorphism through duck typing!

JScript

When you hit the wall that is VBScript’s limited syntax, there is another option: write some functions or objects in JScript, Microsoft’s JavaScript implementation. There can even be performance benefits, especially if you utilise JavaScript’s functional programming potential (e.g. a simple regular expression calling an anonymous function to process matches can make an order of magnitude improvement over the equivalent VBScript).

ActiveX

There are some great third-party ActiveX components available to provide some functionality just not available within Classic ASP. However, by cleverly utilising standard ActiveX components like CAPICOM and ADO, you can greatly extend Classic ASP’s reach, even on the most limiting of shared hosting.

Client-side scripting

Web browsers have come a long way since 2000, and so has client-side scripting. A lot of work has been done to raise awareness about the functional programming and prototype-based object oriented strengths of JavaScript, and standardisation of the browser DOM has allowed new tools to crop up making for a richer user experience. All of this is client side, and thus can be incorporated into a Classic ASP website with no additional effort above that of any other platform.

AJAX

AJAX technologies can add functionality to Classic ASP websites both on the client and at the server side. Just because the acronym mentions asynchronous, JavaScript, and XML, that doesn’t mean that you have to be doing asynchronous XML transfers with JavaScript. Classic ASP can easily provide the remote service for an AJAX client whether they are requesting XML, JSON, HTML or plain text. And AJAX can be used directly from VBScript to synchronously call a service script in another language to perform some complex processing and return results as text or XML.

Some of my future posts will demonstrate these methods, but in the meantime there are many examples out there to Google (or DuckDuck!)

No end in sight?

All good things must come to an end, eventually. The people behind the websites now expect to be able to manage their own content to a large degree, and there are many really good packages out there now, both commercial and open-source, addressing many functional requirements of websites and applications. And the new crop of programmers don’t really want to know about Classic ASP when all the cool work is in, well, anything but Classic ASP.

All of this means that Classic ASP will eventually die out. But eleven years after the last Microsoft update to the platform, I’m still getting work adding new functionality to both websites and intranet applications written in Classic ASP…