Evaluating scripting engines from Netscape and Microsoft.
Although the World Wide Web is very powerful for displaying information, traditional Web pages are static and cannot interact with users in the way that most computer programs do. The birth of client-side, browser-based scripting engines such as JavaScript and Visual Basic Scripting Edition (VBScript) has allowed for the creation of actual client applications that are automatically downloaded with the content of a Web page when it is accessed. The scripts can then execute on the client machine as traditional programs do or in reaction to user manipulation.
Two competing scripting standards, Visual Basic Script and JavaScript, have been introduced to provide client-side execution. The parent company of each engine has designed its scripts to be optimal for a particular set of tasks. JavaScript, created by Netscape Communications Corp., seeks to be the standard for the Internet and the primary automation language used to control and activate Java applications. Microsoft has created VBScript to focus on the corporate Intranet, as a tool in providing client/server solutions. VBScript is specifically targeted at applications based on Web technology, and classic Visual Basic is geared toward traditional client/server solutions.
In this article, I examine both implementations (VBScript included with Internet Explorer 3.0 and JavaScript included with Netscape Navigator 3.0), their strengths and weaknesses, how they are used in development, and some of their target applications. Choosing a scripting engine depends on your intended task because both engines excel in the areas they are targeting.
The most common example of a Web application is a simple form to accept data entry. The form could be stored on a Web server rather than deploying an entire data-entry client written in Visual Basic, C, or Delphi. Clients could then access the data-entry form with any compatible Web browser. The limitations of HTML, however, make all but the simplest applications difficult.
Scripting engines seek to resolve the problem of having no functioning application code on the client. Because the script code is embedded in the HTML, it is downloaded every time the page is accessed. Updating the client is simply a matter of changing the Web files on the server.
The entire information industry has been moving toward client/server systems and away from mainframe computing for years. The advent of Internet/Intranet technology has redefined the balance between the client and the server. The only real options in the past were dumb terminals or networked independent desktop machines. The Web redefines this equation by letting a server instantly download small programs into a client computer, which could then execute the given code.
This new paradigm takes advantage of the strengths of a centralized server model, such as the capacity for centralized maintenance and control. It also lets the individual client take over processing tasks best kept on the client, such as entry verification, user interface functions, and information browsing.
Most of the hype in this area focuses on Java. However, the important day-to-day functionality will probably be supplied by the new scripting engines, JavaScript and VBScript. Although a machine currently requires substantial resources (on the Windows platform, a 16MB Pentium-class machine is the recommended minimum) to run a Java application effectively, the scripting engines are a much simpler extension to browser technology. Java seeks to become an entirely new distributed platform, but the scripting engines provide most of the key functions needed for a "thin" client application.
The two scripting engines available for browser technology are JavaScript (supported by Netscape Navigator 2.0 or later and Internet Explorer 3.0 or later) and VBScript (supported by Internet Explorer 3.0 or later). JavaScript does not have a great deal in common with Java, but like Java the language is essentially a simplified version of C++. VBScript is based on the core Visual Basic language.
Scripting languages allow the creation of functions embedded within HTML code. The engines permit processes to be automated and objects to be accessed and manipulated. Programs can be written with standard programmatic logic such as loops, conditional statements, and math operations. Both scripts can also create HTML code on the fly. This capability lets a program create a custom HTML page based on user selections or input, without requiring a program stored on the Web server to construct the necessary page.
In addition to traditional programming, both scripting languages can call on resources outside of the programming logic itself. For example, VBScript can execute either ActiveX objects or Java applets stored on the client. JavaScript also allows manipulation of Java applets on the client machine. These capabilities enable the client application to be extended by other powerful technologies and act as a type of automation "glue" for a Web-based system.
Both scripting engines are implemented on Windows and Macintosh platforms. At press time, VBScript is limited to Windows NT-, Windows 95-, and Macintosh-based platforms. Microsoft is committed to offering VBScript for Windows NT on the Alpha, MIPS, and PowerPC platforms. Microsoft is also working with Sun, Hewlett-Packard, Digital, and IBM to port VBScript to each company's Unix operating system. JavaScript, incorporated into Netscape browsers, is available on numerous platforms including Windows (3.1, 95, and NT), Macintosh, AIX, BSDI, Linux, OSF, Solaris, and SunOS.
Because Microsoft's focus is Windows 95 and Windows NT, it remains to be seen when VBScript in particular and the ActiveX framework in general will be well supported on the 16-bit operating systems (Windows 3.1 and Windows for Workgroups). Microsoft announced plans for late 1996 support but hasn't publicly demonstrated a working version. JavaScript is already available on the Windows 3.1 platform. If many of your intended users will be using 16-bit OSs, this restriction may be a primary consideration for using JavaScript.
These scripting engines function within the architecture of a Web browser. The Web browser has its own set of user interface rules and general elements that make it slightly different from a traditional application. Therefore, it is important to understand how a script is constructed in order to decide which type of applications would be most effective for its deployment.
A single HTML page might also contain both JavaScript and VBScript code, although this practice could quickly become tedious and error-prone. Requiring a developer to maintain two implementations of code for identical functionality is rarely practical. Adding script to a Web page is a simple process. To add a button to a form, you use traditional HTML form commands. You add a special tag to the HTML code, telling the scripting engine which script to execute when an action occurs. When you click on the button, it calls the JavaScript or VBScript in its entry action code. In Listing 1, both the JavaScript and the VBScript display an alert window that says, "Hello, world." Although the language fundamentals are different (C++ style vs. Basic style), the implementation is nearly the same.
The script begins with the <SCRIPT> tag used to specify the script itself and the language being used for the code. Routines are stored as functions and procedures. Particular functions for a page are generally implemented in the header portion of the HTML code. This is done to ensure that a control does not attempt to execute a function that hasn't finished downloading into the client's machine. Individual calls from the various controls appear in the main body of the HTML page.
Notice that the button code that activates the particular routine is nearly identical to a traditional HTML button that calls a CGI script. The key difference, however, is that the CGI script calls a routine stored on the server, while all of the script processing occurs on the client itself. This permits the processing power of the client to be used in addition to accessing resources such as user interface controls (including scroll bars and radial buttons).
Both JavaScript and VBScript support timer controls, which let events occur at particular intervals. These events might include moving a bitmap around the screen or implementing a clock that is updated every minute.
One solution that developers used recently was defining their applications as a set of frames. Frames provide a way to run several HTML pages on a single user's screen. One central frame could be kept as the controlling frame that stores all of the variables; the content of the other frames could be changed, leaving the variables intact.
Requiring the use of frames, however, is very limiting to the presentation of an application. Now most developers use a technology supported by both Netscape Navigator and Internet Explorer called "cookies." The cookies technology promises to make the scripting engines increasingly useful. A cookie is an item of data that is actually stored in a text file on the client rather than on the server. When a browser activates a particular Web page site, the Web site can store a simple text entry of information on the user's hard disk. This entry may be anything from the information the user entered on a Web form to the exact pages the user has browsed on a site. A Web page can later retrieve this information from the user's browser by having the server send a command with the name of the cookie that is needed. The browser retrieves the specified cookie from the user's drive and returns it to the server. The server can then display a page customized to the particular user.
For script programming, variables can be stored in a cookie that resides on the user's computer and retrieve the information as necessary. Variable information can be stored as the user navigates from page to page through the Web site. Understanding the nature of cookies is important to conceptualizing an application's actual use.
Printing through either VBScript or JavaScript is currently not very advanced. VBScript provides the commands TextHeight, TextWidth, NewPage, PrintForm, and EndDoc. These give a VBScript application rudimentary control of the printer. VBScript has a huge lead in this arena with its support of ActiveX controls. Several available ActiveX printing controls provide everything from Postscript pass-through to print previewing.
JavaScript apparently has no built-in printing functions, although you can create a Web page that the user could print to the printer. If your application requires effective printed output, JavaScript may not be appropriate for your needs.
Netscape provides scripting engine access to Netscape plug-ins (such as Macromedia's Shockwave or Progressive Networks' Real Audio). These plug-ins (like ActiveX controls) cannot be downloaded automatically into the browser and instead require separate download and installation by users. Netscape also allows the control of Java applets from JavaScript. Java applets (accessible to both JavaScript and VBScript) can be downloaded automatically.
Microsoft has exposed the object technology (known as OLE) built into its operating system. The interface for OLE to the Internet has been dubbed ActiveX technology. VBScript can access both ActiveX controls (or OLE controls) and Java applets. ActiveX controls, rather than being registered with the Internet browser (as Netscape plug-ins are), are registered with the operating system itself. Therefore, systemwide objects such as multimedia objects may be used by VBScript. Like JavaScript, VBScript may also access Java applets.
The advantages of using Java applets with either scripting engine include cross-platform availability and download-on-demand features. If a browser doesn't have the particular Java applet needed by the Web page, the Web server can automatically download the Java applet into the client's machine. This provides dynamic content distribution. On the other hand, Java applets currently don't perform very well and use the client CPU and graphics subsystem.
The design of the Java Virtual Machine lets a Java applet run on any machine that has a Virtual Machine engine. This feature requires that every instruction is sent through this piece of processing middleware for simulating execution.
The scripting languages tend to be much faster because they use a natively compiled runtime on the target machine. That means that a single scripting language command actually executes a set of natively compiled instructions rather than calling a routine that must simulate the processing of each instruction (Java). SoftWindows by Insignia Solutions Inc. performs a similar function by simulating an Intel microprocessor running on a PowerPC. Those familiar with the product will understand the performance degradation that occurs when simulating a processor, instruction by instruction.
Despite various disadvantages, the plug-in components (Netscape Plug-ins or ActiveX controls) will most likely be required to some degree in most deployed applications. They provide substantial access to the native client's system resources (such as video drivers, printer drivers, and sound cards). The very technology that enables Java applets to be platform-independent also handicaps the applets when they need to perform optimized or specific tasks.
Included with the Netscape Enterprise and Fast Track servers is a server-side JavaScript compiler, which can maintain states across multiple requests. For speed, the JavaScript is actually compiled and stored on the server, compared with the traditional interpreted execution that occurs with the JavaScript on the client side. The LiveWire engine in the Netscape servers actually executes the compiled JavaScript code. Netscape includes the database object in order to provide server-based access to data. The database object provides a mechanism for platform-independent JavaScript code to use heterogeneous data sources. This means that a server-side JavaScript application could display or alter information in legacy database systems.
In addition to all of the features present in client-side JavaScript, server-side JavaScript has additional features that were intentionally left out of client-side JavaScript so downloaded applets cannot corrupt the client's computer. For example, server-side JavaScript can read and write files and lock and unlock resources.
Netscape has released its implementation of JavaScript for the server; Microsoft has released a beta version of its JScript for use in browsers and other applications that use ActiveX controls, OLE automation servers, and Java applets. Like VBScript, JScript is an interpreter that processes source code embedded directly in the HTML. JScript is available or under development for Windows 95 and Windows NT (including native versions for Alpha, MIPS, and PowerPC architectures), 16-bit Windows, and Power Macintosh. Microsoft is working with third parties to provide Unix versions for Sun, HP, Digital, and IBM platforms.
Microsoft has no announced ship date for the ActiveX Server Framework, but it is safe to say it will be released in late 1996. Until it is released, Netscape stands alone with a scripting engine that can be used in both the client and the server Web implementations.
In Netscape Navigator Gold, all JavaScript code is entered into on-screen tags. (See Figure 1.) There are no code testing, code building automation, or other tools provided by Netscape -but third parties can fill this void. Additionally, programming Netscape plug-ins must be done by hand in HTML - there are no GUI builder tools. The manuals for JavaScript are stored as HTML files instead of a more robust type of online help, which makes them difficult to search and browse with current technology.
Netscape emphasizes the use of Java for development instead of JavaScript. This emphasis seems to be the reason that Netscape has provided no substantial JavaScript development environment. Even Netscape's support for JavaScript on the Web is fairly spotty; finding examples of all but the simplest JavaScript features is difficult.
Microsoft, on the other hand, is using VBScript as one of the cornerstones of promotion for the ActiveX technologies. VBScript itself also has a poor environment for development, without any syntax checking or debugging capabilities. With the beta release of ActiveX Control Pad, however, Microsoft has provided a substantial development environment for creating and maintaining VBScript or JavaScript HTML applications that use ActiveX controls. HTML is displayed in a standard text editing window. To add an ActiveX object, simply select "Insert ActiveX Object" from one of the menus. The object is shown in a window, and you may adjust size and properties. (See Figure 2.) The text editing window automatically reflects these changes.
To attach actions to events, the Script Wizard window shows all of the event procedures for the particular object. (See Figure 3.) By double-clicking on one of the events, you can add that code can to your HTML file. This lets you construct a Web page that uses ActiveX controls and reacts to user events. Although the control pad offers only the simplest functions to design and implement a control-based HTML application, it takes much of the drudgery out of a traditionally dull task. Because there is currently no similar environment for Netscape plug-ins or Java applets that I am aware of, programming these can be more difficult and time-consuming.
When deciding which type of application to design, consider that the scripting engines' primary limitations are speed and control of native client resources (such as video screens and printers). Because the scripting engines are interpretive (rather than compiled like C++), they must be converted into native machine code as they run. Therefore, processing-intensive applications (including math-intensive routines) are not really appropriate for Web implementation (unless the Netscape plug-in or ActiveX architectures are used to optimize key routines).
Also, applications that are screenintensive (those that require many windows, multiple document manipulation, and so on) usually make poor Web applications. The scripting engines' platform independence makes predictable screen presentation nearly impossible. The dynamic aspects of browser technology let the user run on nearly any system, screen, and printer. Making a form appear in the same way on several platforms is difficult at best and impossible at worst.
Finally, despite the advances of the scripting engines, Web access is primarily one-way. For example, how would an application be implemented in which the user needed to post a bitmap picture? Unless a specific control can be added to FTP the bitmap file to your site automatically, this task is nearly impossible to accomplish.
Microsoft has targeted VBScript specifically at the Intranet market. When deploying an Intranet, an information systems person may largely control the browser and controls that are installed on the users' machines. By using ActiveX controls, VBScript, and a suitable browser, the power of the individual client machines can effectively be used while the control of the content and programming of the application remains on the server. This strategy provides the best of both worlds when it comes to client/server processing distribution and decreasing the cost of upgrade maintenance.
If you're deploying on the Internet, you must make many decisions. Both scripts can use Java applets, so this is not a particular consideration, but JavaScript is supported by both Netscape and Microsoft browsers, so writing in JavaScript will give the largest possible audience. If a particular ActiveX control is needed, however, JavaScript doesn't yet support ActiveX objects. With regard to user adoption of a scripting language, both scripts seem comparable.
Another point you may consider is what language your in-house staff is already using. An organization made up primarily of C programmers will have the easiest time adjusting to the use of JavaScript. However, the number of even intermediate users who can adequately program a version of Basic (Visual Basic or VBA) is simply staggering. Will your programming department do the development, or do you wish to give capabilities to your more advanced end users?
The decision is also not as final as it may appear. Code can be ported fairly easily from one scripting language to another. The languages share a basic structure and mostly use the same activation commands. Conversion can be done on a page-by-page basis, allowing a switch to occur piecemeal. Therefore, an organization is not as locked into legacy code as is the case with more traditional programming systems.
Because VBScript is based on the Visual Basic language, it has a much more solid foundation. The available language commands are most likely frozen and stable. At the time of this writing, VBScript is only available on Windows 95 and Windows NT 4.0, making it limited to people running these systems.
LISTING 1.
Scripted Hello World
FIGURE 1
--In Netscape Navigator Gold, all JavaScript code is entered into on-screen tags.
FIGURE 2
--An ActiveX object is shown in a window, and you may adjust size and properties.
FIGURE 3
--To attach actions to events, the Script Wizard window shows all of the event procedures for the particular object.
* Microsoft Corp., One Microsoft Way, Redmond, WA 98052; (800) 426-9400, (206) 882-8080, or fax (206) 936-7329; http://www.microsoft.com.
* Netscape Communications Corp., 501 E. Middlefield Rd., Mountain View, CA 94043; (800) 638-7483, (415) 254-1900, or fax (415) 528-4124; http://www.home.netscape.com.
Table of Contents - October 1996 | Home Page
Copyright © 1996 Miller Freeman, Inc. ALL RIGHTS RESERVED
Redistribution without permission is prohibited.
Please send questions or comments to mfrank@mfi.com
Updated Friday, September 27, 1996