ack in the early days of the browser wars, Microsoft created a huge incentive for existing Visual Basic developers to transition easily into building Web applications by creating a cut-down, interpreted version of Visual Basic called VBScript. VBScript ran as one of two languages supplied with Microsoft's Scripting Runtime library. The other language in the Microsoft Scripting Runtime library was Microsoft's JScript—a knock-off of Netscape's JavaScript.

JavaScript quickly gained credibility and went on to become standardized as ECMAScript. But, in characteristic fashion, Microsoft bucked industry trends by making Internet Explorer support VBScript even while all other browsers standardized on JavaScript.

If that statement is true, Microsoft is keeping the future of VBScript well-hidden.

There were persistent rumors that Netscape planned to support VBScript, but that never happened. A third-party Netscape plug-in did provide partial support for VBScript, but it never quite worked seamlessly, was never distributed by Netscape or by Microsoft, and therefore never reached ubiquity among Netscape clients.

VBScript, almost from its inception, was a stepchild technology that was used mainly for creating server-based Active Server Pages (ASP) scripts. ASP and VBScript proved to be such a popular and easy to use combination that millions of dynamic Web pages were written in VBScript. But people who used VBScript on the server were often forced to learn and use JavaScript for their client-side code.

Right from the start, if you used VBScript you had a dilemma: If you were planning a commercial site, you had to choose JavaScript for client-side code or agree up-front to shortchange a percentage of your potential audience. Even Microsoft, on its MSDN site, tacitly acknowledged VBScript's shortcomings; a majority of its client-side script examples—and almost all the "live" client script for the site—were written in JavaScript.

Today, even Microsoft's own IE doesn't support VBScript on all platforms—you'll find VBScript support is missing in all but the full Windows releases. IE for the Mac doesn't support VBScript—but it supports JavaScript. IE for the PocketPC (PIE) doesn't support VBScript either, although version 3 promises "limited" support. The reason generally given is that memory on small devices is at a premium—yet Microsoft saw fit to support JavaScript, even in earlier versions. It's rather obvious where its priorities lie.

The fact is that unless you're working on a highly-controlled intranet, where 100 percent of clients are Windows clients running IE, JavaScript was—and still is—your only choice for writing client scripts that work in all browsers. Yet Microsoft still maintains the fiction that VBScript will somehow break out of its IE playpen and become a viable client-scripting language. For example, here's a quote from MSDN:

"Microsoft is fully committed to evolving implementations of both JScript and VBScript to a level where each language is functionally equivalent. So don't feel that you need to commit to one just to ensure that you are investing in a language that has a future."

If that statement is true, Microsoft is keeping the future of VBScript well-hidden. The most telling stroke against VBScript is that with two cumulative releases of the .NET framework and Visual Studio now behind us, there's still no sign of a VBScript.NET. There's a JScript.NET—has been since the early beta releases—but no VBScript.NET.

Does VBScript Have a Future?
I once believed that VBScript would rapidly become the script lingua franca of the Internet. After all, VBA, another cut-down version of Visual Basic, found its way not only into the Microsoft Office suite as the primary macro language, but also into a host of other commercial products. Because VBA and VBScript are fundamentally similar and therefore attractive to the same large universe of developers, one might rationally assume that VBScript would make an equally successful transition into Web products as VBA did in desktop products. But that didn't happen. If functional equivalence with JScript were a goal, Microsoft could have created a VBScript.NET. At one point, they had a third-party company create a proof-of-concept VBScript.NET, according to David Simmons of SmallScript Corp.—but Microsoft has apparently made a unilateral decision not to bring the language along into the .NET family. Unless rectified quickly, that omission represents a hard stop for VBScript, whereas VBA's future looks a bit more stable for the short term, if not for the long term.

From all appearances, VBScript is on a path to extinction. And with all due respect to VBScript, that's probably a good thing. In spite of the broad industry support for JavaScript, Microsoft probably could have garnered equally wide support for VBScript if it had ported the language to other platforms early in its lifecycle. However, as that didn't happen, there's little reason now for Microsoft (or its customers) to maintain the fiction that VBScript has any serious future as a Web language. I interpret VBScript's absence from .NET as Microsoft's tacit agreement that VBScript has no future. In my opinion, the lack of client-side support and the absence of VBScript.NET should serve as warning signs to developers or organizations using or planning to use VBScript.

Of course, VBScript aficionados are perfectly free to ignore these warning signs and continue to use this familiar language; but unless Microsoft has some sudden radical VBScript epiphany, those who do should be prepared for heartache and frustration down the road. By the way, if you want to buy the domain name VBScript.NET, it's for sale.