VBScript is not a programming language platform designed for production servers in large enterprises.
It’s a light-duty, interpreted scripting language for use on your home machine, personal web server, or two-server small business. While I’m a fan of many Microsoft products, VBScript is not one of them.
My first major use of it was five years ago when I used it at a past employer because of an architectural decision made years ago to create and maintain a custom in-house enterprise “job-control” system based entirely on VBScript/WSH (Windows Scripting Host), calling in turn a library of other WSH files created with VBScript. Most IT folks working there that had a reason to know had an inkling it wasn’t the most up-to-date technology choice, but they explained away the moving forward with it like this: “We were just mainframe programmers trying to replicate the mainframe jobs and report-generation scripts on Windows servers, and this was all we had available at the time.”
PowerShell had long been available upon my arrival, but the investment in VBScript development and deployment was so pervasive at that point that moving away from it would have been very expensive. I can respect a cost-based decision like that, even if the technology-side of it doesn’t work for me in the least.
If you are in a position of technology leadership, please don’t put your organization in that cradle of fragility on a very outdated scripting language. As a result of that job, I’ve written far more VBScript code than I would ever care to admit or even bother to remember. Fortunately, you have choices in 2017 when it comes to scripting, and VBScript should be dead last on that list.
Anything VBScript (or it’s forgotten [but supported] cousin JScript) can perform against the Windows Scripting Host [engine], .NET batch-jobs, Powershell or Python can generally do better:
- with less code,
- better testability,
- far better error-handling potential,
- less technical debt for others to deal with in the future when modifications/expansions are necessary,
- better reference documentation,
- far better third-party library/open-source support,
- object-oriented class structures, and
- better integration with OS libraries.
What’s my vote for the happy path? From my perspective as a developer (not a sysadmin):
- .NET command-line executables
- PowerShell scripts (this should be the choice for sysadmins, in my opinion)
Fatal Flaws
While VBScript is better than using Windows shell command-line for some scripts, it’s fatal flaws are as follows:
- Very loose-typing of what would be baked-in primitive value-types in any other modern programming language. What would be garden-variety primitive data-types (integer, decimal, char, et al) in VBScript are always an anonymous “object” type. As such, any variable can take on any data-type at any time for the life of the object. Type-safety is just not a thing in VBScript, hence it is error-prone and allows you way too much freedom as a developer. The only way you can keep track of which variable should be handling a type consistently is to use a naming convenion like “intVariableName” for integers or “strVariableName” for strings, etc.
- Worst error-handling and debug support of any language I have ever used, without a doubt. You won’t even get an exact line-number from the scripting engine/interpreter 99% of the time, and you won’t know you have an error in your script until you run it. Trying to develop a script hundreds of lines long with methods to boot? Good luck finding your syntax error, or data issue without outputting every little thing to screen output.
- Zero support for reference types (no custom OOP or .DLL support), other than what’s baked into the Windows OS frameworks and COM-visible to the script interpreter. There is a work-around for this using digital duct-tape and baling-wire, but it’s neither pretty, a widely supported idea, nor a good use of your time. I’ve written “classes” in VBScript out of need, in order to be able to reuse code structures, but it was a complete hack, and the time would have been much better spent writing a .NET utility and/or library class to accomplish the same thing with a command-line executable. The class worked, but it was definitely a hack for which the language was not designed.
- No facility for multi-threaded execution.
- Industry-wide lack of code-editor / IDE / syntax support (ever heard of Intellisense?). There is a third-party editor you can buy that will give you something reasonably approximating Visual Studio’s Intellisense, but it’s a one-off solution that you will have to buy yourself. Not even Microsoft’s Visual Studio has had support for VBScript since Visual Studio 2005. That is, the company that created the language only bothered to offer support for developing it in their IDE for a few years, then dropped it cold-turkey. If Microsoft doesn’t care about VBScript, and advocates against its use in favor of Powershell, why should you or I care when so many better alternatives exist?
- It’s a Microsoft-proprietary and niche technology with neither open-source nor wider industry support. Development/expansion on it as a scripting language ceased long ago. There is zero support from Microsoft or its vendors for VBScript – that well dried up many years ago. The script interpretation-engine was never open-sourced, presumably because it’s on every Windows distro, and hasn’t been actively developed since…I think it might have been last updated to version 5.8 during the WinXP years.
- Close to zero vendor library support, unless you count random blog entries with sometimes untested code from ten plus years ago from random hobbyists or admins who are dabbling with it. Additionally, there is zero open-source library support for VBScript.
- It’s not DOM-aware like Javascript is in modern web browsers, so don’t even bother with browser-scripting, not even for firewalled intranet sites with an exclusive IE-based browser audience. No browsers except very outdated versions of IE even support it for browser-based scripting. VBScript was relegated to the trash heap of classic-ASP web page development years ago, and no-one really wants to admit that they ever had a hand developing web-pages with that technology, lest they be put in charge of the conversion away from that stack (been there, done that).
- Potential for misuse. It’s a scripting language, not a programming language. If the only reason you use it is to call batch/command-line executables – written in any language – then ok. If you are using it for anything more than that, then you might need to rethink your job-control architecture and move it gradually to a newer platform with a function/routine library backing it up. .NET C#/VB.NET, Python, Go, and C++ are all good choices for batch program writing. I’m sure there are many other good choices depending on your surrounding architecture.
- Do we need more reasons not to use VBScript in the enterprise environment?
I am just not a VBScript fan, for the quantifiable reasons above. I was skeptical when I first started using it (forced to use it), and as time wore on I came to know that I was really wasting my time and the company’s resources by using it further, and only adding time/expense to a future enterprise technical-debt burden that would take years to unwind and mitigate. I have no interest in extending it’s lifespan through usage, even though every version of Windows, client or server, supports it use. If a client specifically needed it, I would code with it, but very, very reluctantly, and not without generous discussion, dissuasion, and dissent with an eye to a much better solution alternative.
PowerShell is what you need
Use Powershell if scripting “jobs” for Windows servers. Powershell has been around for at least a decade now – if not more – and has well proven it’s suitability and efficacy for enterprise scripting and job control with library support from Microsoft and a huge community of sysadmins who are eager to help you find the solution you need.
VBScript (along with JScript, not JavaScript) came to life in the late 1990’s with the introduction of Windows 98/Windows ME and was first popularized for use with Windows Server 2000 (circa 1999) and WSF (Windows Scripting Foundation). I’ve always thought JavaScript was a badly designed language – and it leaves much to be desired – but it’s nowhere near as bad as VBScript. Just walk away from the VBScript (or JScript, which accesses the same limited COM object model as VBScript), and walk quickly please.
Almost twenty years has passed since it’s introduction as the darling of sysadmins, and much, much better alternatives for administrative and browser-scripting have evolved in that time.
Code Agility 