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.
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.
- 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!
- 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
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…