Is WSC Right for You?
There are many ways to write reusable code. You can use binary code or scripting code. If you use scripting code, you can choose to import subroutines, use writable objects, or use Windows Script Components (WSC). Here's a quick look at each of these approaches and their pros and cons.
Scripting Code vs. Binary Code
Scripting code and binary code both have advantages and disadvantages. The main advantage of using binary code is faster performance. Scripting code is interpreted, whereas binary code is compiled. Executing compiled code is inherently faster than executing interpreted code.
The main advantage of using scripting code is that it's well-suited for code prototyping because you write scripting code in a text-based file. You can quickly create a script file, but more important, you can easily change its code. You just make the necessary changes then save the file-you don't have to recompile the code before you test the changes. Once you're happy with how the scripting code works, you can easily port it to a compiled format in Visual Basic (VB).
A text-based file is an advantage for code prototyping but a disadvantage for code security. Because you download and distribute scripting code as plaintext files, those files are more vulnerable to snooping and tampering than compiled binary code files.
Scripting Code Options
If you want to use a scripting language to write reusable code, you have several options. One option is to import subroutines into the scripts you write. Typically, you must write such subroutines in the same scripting language as the rest of the script.
Another option is to use writable objects. The phrase writable objects is deliberately generic. In this case, writable objects are similar to WSC objects, except the writable objects are language-specific because the scripting language makes the writable objects available. Thus, for example, writable objects equates to JavaScript objects if you use any dialect of ECMAScript (e.g., JScript, Netscape's JavaScript) or VBScript classes if you use VBScript 5.0.
Whether you should import subroutines or use writable objects depends on your application. For example, if you're writing an Active Server Pages (ASP) file, you need every little bit of possible performance gain. Importing ready-to-use code is the fastest way to reuse code-and the ASP runtime engine provides a special directive called <INCLUDE> to import external script files. Thus, using subroutines is preferable to using writable objects because you can import subroutines. You can't import writable objects. Instead, you must instantiate them, which adds setup time, thereby reducing performance.
In HTML pages, Windows Script Host (WSH) scripts, and other client-side code, flexibility and ease of maintenance are often more important than small gains in performance. Because writable objects are more flexible and programmable than imported subroutines, using objects in client-side code is preferable, no matter whether you're using VBScript or JScript. In addition, writable objects are preferable because neither VBScript nor JScript supports a standard mechanism to import external files. Although you can use workarounds to import external files, these workarounds don't provide clean, elegant solutions.
Importing subroutines and using writable objects are often effective, but they're inherently tied to a specific scripting language. Sometimes, you need reusable code that spans across different scripting languages. In these situations, you'll want to use WSC because WSC leverages XML and scripting code to create COM objects. In addition, WSC is an excellent option if you're writing reusable code for WSH and the only option if you're writing reusable code for platforms other than Windows 2000 and WSH 2.0.