VBScript is a subset of the Visual Basic for Applications language. There are several features that VB and VBA programmers have become accustomed to that are not present in VBScript. This does not lessen the usability of VBScript: it only serves to reinforce that VBScript is meant for scripting and not full-blown client/server application development or COM component development. Let's take a look at a few of the larger differences between VBScript and VBA:
VBScript is a weakly typed language.
Unlike Visual Basic and Visual Basic for Applications, in which the developer can define the data type of a variable in advance, all variables in VBScript are variants. There are types to handle different types of data; you can use these as you would the traditional data types in Visual Basic. For more information, see Chapter 3.
VBScript does not support early binding.
Because variables are untyped and code is not compiled, all external objects instantiated in VBScript code are necessarily late-bound. This has a number of implications. First, late binding typically entails a substantial performance penalty in comparison to early binding. Second, while the properties and methods of early-bound objects can be examined in Visual Basic or hosted VBA environments using the Object Browser, this is not the case with late-bound objects. Finally, the help facilities available for early-bound objects in VB and VBA (like Auto List Members and Auto Quick Info) are not available, making syntax errors more likely and ready access to good documentation all the more necessary.
VBScript does not support named arguments.
VBA supports both positional and named arguments for most functions and procedures. For example, the VBA MsgBox function can be called using positional arguments as follows:
lResult = MsgBox("Delete this file?", _ vbYesNo Or vbQuestion Or vbDefaultButton2, _ "Confirm File Deletion")
A method call using named arguments takes the following form:
lResult = MsgBox(Prompt:="Delete this file?", _ Title:="Confirm File Deletion", _ Buttons:=vbYesNo Or vbQuestion Or vbDefaultButton2)
Note that while positional arguments must occur in a predefined sequence, named arguments need not. At least in our experience, more advanced programmers tend to prefer positional syntax, while more novice programmers tend to prefer named arguments.
Given all of this, it is unfortunate that VBScript supports only positional arguments.
VBScript does not have an IDE.
There is no integrated development environment for VBScript that parallels the IDE for Visual Basic and Visual Basic for Applications. Development tools are available for all of the environments in which VBScript is used, but all fall short of the power, simplicity, elegance, and ease of use of the VB/VBA IDE.Typically, web developers have had their own environments for writing their code. VBScript for the Web, whether it is client-side or server-side, is embedded inside of a tag. This allows web developers to continue to use their tool of choice even when using VBScript; a wide array of tools for web script development are available. Scripts for WSH can be created with the use of a simple text editor like Windows Notepad. Outlook comes with its rudimentary IDE (a glorified version of Notepad) for attaching code to Outlook forms.
We should also mention one difference between VBScript and VB/VBA that developers and commentators often emphasizenamely, that VBScript is slower than VB/VBA. This contention, though, raises more questions than it answers. First, if VBScript is used as "glue code," as it typically is, then the limiting factor in a VBScript programs performance will be the components it consumes, rather than theperformance of the script itself. Second, performance cannot be measured in a vacuum. Rather than asking whether VBScript is faster or slower in the abstract, we have to consider the particular tasks for which it is being used.
But practically speaking, "Which is faster?" is usually the wrong question. The right question to ask is, "Which is fast enough?", which is a very different question. "Which is faster?" is a bad metric to use when choosing or comparing programming languages. Many factors influence performance, and not all are obvious. Code reliability, maintainability, robustness, and cost of development are all important factors to be considered along with performance.
Performance ("faster" and "slower") is also inherently hard to measure, since the terms themselves are more subjective than objective. Do they refer to "UI snappiness," "time to first byte," "throughput," or "page faults per second," or to something else?
As a programming language, VBScript offers acceptable performance along with an elegance and simplicity that make it a valuable tool for the range of scripted applications for which it was developed.