Web technologies are changing at a phenomenal rate, and every time a new technology is introduced you can almost guarantee that within six months someone will extend it, enhance it, or otherwise alter forever the way it works. Nowhere is this more evident than with Web programming, and with JavaScript in particular. In the previous issue we examined JavaScript (along with VBScript) as we explored Web scripting languages. Here we'll look again at JavaScript, focusing on two implementations: Netscape's JavaScript and Microsoft's JScript.

JavaScript was introduced to the world as LiveScript and before anyone could punt, Netscape changed the name and the language's fundamentals. JavaScript is already in its third revision, and although every revision has taken the scripting language a step further in functionality, the constant changes can be frustrating for Web developers who want to create pages that work in the broadest spectrum of browsers. After all, what good is an awesome JavaScript-powered page that cannot be accessed by millions of the site's visitors?

As if rapid change were not difficult enough, Microsoft implemented its own variation of JavaScript, called Jscript, currently in its second major revision. Just as Netscape's JavaScript is designed to be used with Netscape Navigator, JScript is designed to be used with Internet Explorer. Although the two implementations are similar, each includes some unique features. And the fundamental differences between the two mean that your wonderful JavaScript-powered Web page may not work in the "other" browser, eliminating perhaps millions of potential visitors. So, as a Web publisher, what do you do? Do you adopt one scripting model over the other? Or do you try to create scripts that will work with both JavaScript and JScript?

To help you answer these questions, we will take a closer look at both languages, followed by a head-to-head comparison, including specific pointers on how to create scripts that will work in both Netscape Navigator and Internet Explorer.

NETSCAPE'S JAVASCRIPT

Sure, JavaScript is great for transforming lifeless Web pages into dynamic, fully interactive pages with real-time response. But what if you want something more? What if you want to move beyond the traditional boundaries of Web scripting? What if, for example, you want to use JavaScript to perform both client-side and server-side tasks? Can JavaScript meet the challenge?

The answer is a resounding yes. JavaScript has evolved from a quick fix for client-side scripting to a comprehensive framework for meeting both client-side and server-side development needs. The client-side framework that you rely on when working with Web pages is implemented in the Netscape Navigator browser. When you work with back-end processing, you rely on server-side JavaScript. The server-side framework is an extension for Netscape servers implemented in a product called LiveWire. Within Netscape FastTrack or Enterprise servers, LiveWire and JavaScript end the need for gateway scripts and form a comprehensive server-side solution for file manipulation, database management, and more.

Right now you may be saying to yourself, wait a minute, I thought JavaScript was an open standard that wouldn't tie me to a specific company or product. That was the idea, but things haven't exactly turned out that way. Ultimately, you are tied to specific Netscape products and technologies when you work with JavaScript. Still, there is an upside to the tight integration of JavaScript into Netscape's technology model, especially when it comes to Netscape ONE (Open Networked Environment).

Netscape ONE is designed to be a cross-platform development environment that includes many different technologies for creating Web-based applications. A key component of this environment is LiveConnect, a framework for connecting technologies such as Java, JavaScript, and plug-ins. With it you can create scripts that update Java applets, Netscape plug-ins that interact with Java applets, and Java applets that call script functions. Although LiveConnect is a powerful innovation, it's not really a separate technology but rather an extension framework for existing technologies such as JavaScript. Thus you use the LiveConnect extensions for JavaScript to create scripts that interact with Java applets and Netscape plug-ins.

MICROSOFT'S JSCRIPT

Microsoft recognized the potential of JavaScript almost immediately, and implemented its own version, Jscript, in the process changing some of the scripting language's fundamentals. But JScript is also a comprehensive solution for Web development. Just as JavaScript is tightly integrated into Netscape's technology model, JScript is tightly integrated into Microsoft's model. It is designed to be a full implementation of JavaScript with specific enhancements for the Internet Explorer browser. Because of this, the JScript and JavaScript object frameworks are similar, and you can use JScript in Web pages just as you use JavaScript.

Beyond the similarity of their object frameworks, JScript and JavaScript are strikingly different in the way their object models are created and implemented. JScript's core language functionality and baseline object framework are defined in the JScript specification, extended with the Internet Explorer's object model for scripting. It is within this enhanced object model that JScript obtains most of its functionality. Contrast the separation of core functionality and the browser object model with Netscape's integrated model, where the core functionality is tightly woven into the object framework and you may conclude that Microsoft chose a path for implementing Jscript that was not only different but better.

The separation of the Internet Explorer object model from the JScript object model allows Microsoft to do some pretty amazing things, one of which is to make the Internet Explorer object model accessible to any other scripting language (such as VBScript) implemented in the browser. This enables Microsoft to extend the functionality of both JScript and VBScript by updating Internet Explorer's object model. This same object model is also part of Microsoft's ActiveX framework.

ActiveX, like LiveConnect, is a framework for connecting technologies. Unlike LiveConnect, ActiveX uses an enhanced object linking and embedding (OLE) interface to connect ActiveX controls, scripts, and Java applets.

Behind the scenes, JScript provides the interfaces and hooks that allow all the elements to connect together.

On the server side, the object model for JScript is defined in the Active server framework, available in any of Microsoft's Active servers including the Internet Information Server Versions 3.0 and later.

JAVASCRIPT VS. JSCRIPT

The versatile and dynamic nature of both JavaScript and JScript derives from their strong ties to their respective frameworks. Thus JavaScript is ideal if you're using Netscape clients and servers, and JScript is the obvious choice for those using Microsoft clients and servers.

On a corporate intranet you can choose which clients and servers to support. On the Web you don't have the luxury of deciding who will visit your site. For this reason, familiarity with the strengths and weaknesses of both scripting languages can help you determine when to use one or the other.

When you examine core functionality, you will find that JavaScript and JScript are quite similar, especially when you look at their syntax and operator set. If you know a bit about Java or C/C++, most of the operators should be very familiar.

The availability of built-in functions and control flows gives JavaScript an edge over JScript because of the introduction of a new version of JavaScript in Navigator 4.0 that adds control flows such as select/switch case, do-while looping and keyword labels.

The Built-In Functions section examines the core functions supported by JavaScript and JScript. These functions are used to perform common operations such as evaluating expressions, URL-encoding strings, and converting strings to numeric values. Only JavaScript supports functions for data tainting. With data tainting enabled, you can overcome the security restrictions that limit the ways your scripts can access a browser's history list. These lowered restrictions allow your scripts to extract the actual URLs in the history list, which could give someone a list of every Web site a user has visited.

Data tainting also allows scripts to extract information from documents in different domains. Thus a script running in a framed document on your domain could access links, images, and objects in a document from a different domain that is loaded in another frame. Because data tainting is a security concern, it is designed to be used on intranets or secure environments and can only be accessed when the programmer sets a specific environment variable.

Control Flow looks at the ways you can manage program flow within your script. In this area, JavaScript has another apparent advantage over JScript. Keep in mind, however, that case-switch and do-while structures can be implemented using the fundamental controls supported by JScript.

OBJECT SUPPORT

Both JavaScript and JScript are object-based, and you can learn a great deal about them by examining their object models. Although these object models were originally designed to be compatible, the two languages have evolved in different directions. As a result, each supports a slightly different object set.

CREATING CROSS-BROWSER SCRIPTS

More than 60 million people currently access the Web, and of these millions, 30 to 35 percent use Internet Explorer while 55 to 60 percent use Netscape Navigator. Because these two browsers dominate the market, your goal may be to create scripts that run in both. The secret to doing so is to exploit the common ground between the JScript and JavaScript object models. This may seem like simple common sense. However, very few Web publishers truly understand the differences between JScript and JavaScript, and even fewer have ever plotted out exactly how JScript and JavaScript relate to each other.

As you develop scripts, keep in mind that the JScript and JavaScript specifications are fluid. With each new edition of Internet Explorer or Netscape Navigator, the corresponding language implementation will probably gain new functionality. If you want to use a particular feature exclusive to one, you should create your script so that it either informs users that the script uses a feature not supported by their browser, or that it runs in both browsers without errors.

The secret to creating scripts that use features exclusive to a particular language yet run in either browser is to provide different sets of functions, one set to be executed by Internet Explorer and another to be executed by Netscape Navigator. Because browsers do not validate functions until execution time, the separate functions will not cause a browser to report errors.

A script for cross-browser support.

<SCRIPT LANGUAGE="JavaScript"> <!-- //initialize variables browserName = "" browserName = navigator.appName function shield() { if (browserName == "Microsoft Internet Explorer") { ieCall() } else if (browserName == "Netscape") { nsCall() } else genCall() } function ieCall() { //insert Internet Explorer and JScript-specific statements //or Internet Explorer and JScript-specific function calls } function nsCall() { //insert Netscape Navigator and JavaScript-specific statements //or Netscape Navigator and JavaScript-specific function calls } function genCall() { //a contingency function in case other browsers start to support JavaScript. //You could insert generic statements or calls to generic functions. } // --> </SCRIPT>

You can also execute unique functions for different browsers by checking browser name and version information with the navigator.appName and navigator.appVersion properties. Here, you check for both browser name and version before calling a specific function. But the coding for this can get rather messy; one way to streamline your script is to extract the browser name and version information from the navigator .userAgent property, which reports a summary list of browser information. In this way, you only have one property to check instead of two.

You can also ensure that only scripts of the specific JavaScript version supported by the user's browser are executed. Use the <SCRIPT> tag for this, for instance:

<SCRIPT LANGUAGE="JavaScript"> <SCRIPT LANGUAGE="JavaScript1.1"> <SCRIPT LANGUAGE="JavaScript1.2">

Note that because Internet Explorer does not recognize the JavaScript 1.1 or JavaScript 1.2 values, it's usually better to use the cross-platform script. In this way, you can allow users with all types of JavaScript-enhanced browsers to get the most out of your Web page.

Source: PC Magazine