JavaScript comes of age Understanding the implementation of JavaScript and its many uses on your site

August  1999

When JavaScript first emerged, Webmasters and developers were a bit reluctant to use it because the majority of available browsers did not support it. Now, however, most of the hits on your pages are coming from browsers that can understand the language, although the option to disable it is present. And, in addition to browser implementations of the language, JavaScript has moved onto the server side. This month Allen discusses JavaScript in its expanding environment and the numerous uses it has today. (2,600 words)

Mail this article to a friend

avaScript has truly come a long way since it was first released in beta versions of Netscape Navigator 2. The language has progressed in the Netscape line of products, and has made important appearances in various Microsoft implementations as well. Now more than ever, this once small-time language is stepping up to play ball with the big boys. It has gone beyond its uses in Web pages and is gaining a foothold on the server side. Microsoft has implemented it within its operating system to perform tasks that are too complex for batch files, and there are rumors that it will soon show its face in the world of Linux. All of this publicity has helped catapult the language into prime time.

JavaScript is considered a complement to the Java language, and many implementations allow interaction between JavaScript and Java; the two are also similar in syntax and semantics. It is worth noting, however, that JavaScript by itself does not really provide the ability to build an entire application. By this I mean that there are no tangible elements in the language that automatically build objects that you can visually see. Rather, the language acts as the glue between such components as HTML files, images, and applets. Using JavaScript to marshall these disparate components, a programmer can build a robust Web application centered around, but not entirely composed of, JavaScript code. True, JavaScript can create some new objects, such as a DHTML menu, that have these items built in, but the core language does not contain this functionality.

We will look at JavaScript's history, which provides a great foundation for understanding where the language might go next, and then move on to an examination of the environments that support it. I will go over the varying levels of support in browsers, and touch on the different types of implementations. We will also look at putting the language to use, and why it is more important than ever for a Webmaster to be well versed in JavaScript's various incarnations and uses.

A little history
With Netscape Navigator 2 came the birth of JavaScript (originally called LiveScript). This simple yet powerful interpreted programming language was contained in HTML pages, where it was parsed and executed by the browser after loading. It provided a means to interact with objects on a page and gave us the ability to create content, such as a date stamp, at the moment at which the page was rendered. In addition to this use, it was able to provide a first line of verification for data entered into form elements, preventing inaccurate data from being submitted.

Shortly after this initial release, Netscape began work on its 3.0 version of Navigator, which when released contained JavaScript 1.1. This version attempted to provide a foundation for a security model (data tainting, which was later deprecated). More successfully implemented were the ability to place scripts in an external file and call them with the SRC attribute of the <script> tag, communication between Java applets and their plugins (LiveConnect), and other minor enhancements. This version really was the first step toward the ultimate standardization of the language, and the foundation for the many other implementations that were to follow.

After the immediate success Netscape was seeing with this language, it became obvious that JavaScript was a good thing and here to stay. Following the market trend, Microsoft soon began work on an implementation of its own, which was dubbed JScript 1.0. This first appeared in its 3.0 version of Internet Explorer; however, because Microsoft based its implementation on Netscape's published documentation, it lacked some of the undocumented elements. Due to these omissions, it was hard for Webmasters and developers to rely on the use of certain objects. In order to avoid potential pitfalls, they built checks into their programs; the following code snippet, which checks for support of the Image object, is an example:

if (document.images){
  // perform tasks that rely on the Image object
}

Internet Explorer went through several minor releases on the various platforms that it supported (Mac OS, two flavors of Unix, and, of course, the Windows operating system). However, the JScript support in the browsers that ran on these platforms varied. For instance, IE 3.0 for Mac OS did not have JScript; it was, however, added in 3.01. Unlike its Windows counterpart, IE 3.01 for Mac OS supported the Image object. On the Windows side, Microsoft included a second version of its JScript engine that fixed some bugs and provided limited support for other JavaScript 1.1 items, such as the use of the SRC attribute of the <script> tag. But, as you may have noticed at the time, Microsoft pretty much made a mess of JScript in its 3.0 browsers. Support varied, but despite the problems it was able to close the scripting lead on Netscape's implementation.

As many of you know, while Microsoft and Netscape were fighting it out to be number one and advance the JavaScript language, a little browser called Opera (see the Resources section at the bottom of this page for Opera Software's URL) was released that also supported the language. Like Microsoft, Opera fashioned its implementation based on Netscape's published documentation, but it learned from Microsoft's errors. Like Internet Explorer, some things were left out, but in the case of Opera these were mostly items that the Opera programmers consciously chose not to support. Such items included data tainting, MIME types, and LiveConnect.

In any case, JavaScript 1.1 was responsible for the language becoming widely accepted. And it quickly became obvious that some kind of standard needed to be developed. This is what led to a version of the language (eventually was dubbed ECMAScript) being submitted to and eventual adopted by the European Computer Manufacturers Association (ECMA). The standard itself contains only the objects, properties, and methods that make up the core of the language. It has been left up to the company implementing it to extend it with client-side, server-side, and native-OS-level extensions. Because of the adoption of this standard, both JScript and JavaScript are now technically speaking implementations of the ECMAScript language.

As Webmasters, we are often called upon to perform the common tasks of the design of our sites, but we also must work on how they are created and delivered. Some of this has to do with operating-specific tasks, such as transferring files, or with the creation of the content, such as obtaining data from a database. There is functionality which we would like to perform on the client side, as well. Up until this point, we have only talked about using JavaScript on the client side; however, the language has grown to the point where it has expanded past these boundaries and found implementations elsewhere. These implementations, and the language's progress within browsers, are discussed in the following sections.

Continuing support within browsers
Since the good old days, both Netscape and Microsoft have released new versions of the language. Netscape has released versions 1.2 and 1.3, and it is currently working on 1.4 for Navigator 5.0. Microsoft, on the other hand, has released 3.0, 3.1, and 5.0 in its browsers, and, as you can tell from the jump in versions, it also released engines with other products. These products include its Internet Information Server Web server (IIS) and its Visual InterDev development environment. In addition to the releases from these two companies, we have also seen Sun implement JavaScript in its HotJava browser using a Java implementation of the language, and Be implement an experimental version in the NetPositive 2.1 browser that runs on its BeOS operating system.

What this means to the Web developer is that the language is maturing at a rapid pace. Even though companies are implementing new objects, properties, methods, and event handlers with each release, all the different versions of JavaScript are becoming increasingly similar in terms of what sort of syntax is supported. As a Webmaster, you have more and more code at your fingertips with which to work. However, because support changes with each version of the browser, there is a large mix of versions out there. To help, I have included the following table to outline the various browsers and the most common version of the language they support.

The addition of JavaScript usage on the server side
In addition to using the language on the client side, JavaScript is also used on the server side in Netscape's Enterprise Server and Microsoft's IIS, as mentioned above. Both of these Web servers use the language to build pages, but their implementations are different. This difference involves more than just a few objects or properties -- the two implementations have fundamentally different orientations. Let's take a quick look at each and the theories that drive them.

Netscape's implementation on the server side leans it more toward Web-based applications. It requires that the HTML files containing the JavaScript be compiled into single file. In addition to this, the language itself adds database, file, mail, and other objects for more server-like tasks, such as managing connections to a database and file system accesses, or processing e-mail. But all of this has to be compiled into a single file, and although it improves performance, it also limits the use of the language. It is simply not practical to build an entire site with a collection of compiled files.

Microsoft, on the other hand, implements JScript in the Active Server Pages (ASP) functionality of its IIS Web servers. Unlike Netscape's server-side JavaScript, ASP allows you to place code into your HTML pages that is not interpreted until a page is being served to a browser. This lets you quickly change a script if you find a bug or need new functionality -- it's like changing the HTML on a page. It is this ease of use and lack of compilation that has helped push the use of ASP among the Web community, and helped make Windows NT a viable Web platform.

Finding its way into the operating system
Recently, JavaScript has been implemented within the operating system itself -- specifically, Microsoft's operating system. Windows includes a program called, the Windows Scripting Host, that is used to execute JavaScript code. This particular implementation, created by Microsoft, allows programmers to use JavaScript to automate tasks, in much the same way that they have traditionally used batch files -- but with greater functionality and control. You can create, move, and delete files and folders. You can open applications and load files into them, and you can automate many of the daily tasks administrators need to complete.

At this point, Webmasters might not have much use for running JavaScript within the operating system, except for moving files or for batch renaming. However, with the rumor of another implementation for Linux, and the fact that there is now a Java implementation of JavaScript that has already been incorporated to produce a JavaScript shell, I would expect its uses to grow. With this growth will come increased functionality that could potentially allow us as Webmasters to better handle Web logs, monitor processes and applications, and perform the everyday maintenance we must do.

Concluding thoughts
As you can see, JavaScript has come a long way since it first appeared, and it has continued to mark out a path to the easy construction of sites and applications. As a Webmaster, you need to expose yourself to the language if you have not already done so. Familiarize yourself with the core objects that are defined by the ECMAScript standard. Learn the client-side and server-side implementations that allow you to build and manage your pages. Start to utilize the operating-specific implementations supported by the Windows Scripting Host (and other systems in the near future, hopefully). JavaScript, like HTML, can become a common thread for activating your work tasks and enhancing your users' experience.

You can use JavaScript for much more than just popping up alert boxes, scrolling text, or writing dates to HTML pages. It is one of the core technologies, along with HTML, style sheets, and, soon, XML, that need to be part of a Webmaster's toolset. It puts the D in DHTML, and provides the dynamics we also need as a resource on the server side. JavaScript is a powerful language, and if you use it to its full potential, it will continue to help put the master in Webmaster.

Resources

• ECMA was responsible for the standardization of the JavaScript language:
  http://www.ecma.ch
• Netscape's DevEdge Online site provides access to its official documentation on the support for the JavaScript language:
  http://developer.netscape.com
• Microsoft's Developer Network has an area dedicated to its various implementations of JavaScript:
  http://msdn.microsoft.com/scripting
• Mozilla.org, the central location for Netscape's open source project, contains information on the direction of JavaScript in future Netscape products:
  http://www.mozilla.org/js
• The Cut-N-Paste JavaScript site is packed full of scripts that can be downloaded and used for various tasks:
  http://www.infohiway.com/javascript/indexf.htm
• Opera Software:
  http://www.operasoftware.com
• Be:
  http://www.be.com
• Full listing of previous Webmaster columns in SunWorld:
  http://www.sunworld.com/common/swol-backissues-columns.html#webmaster
• Web server performance/management articles listed in the SunWorld Topical Index:
  http://www.sunworld.com/sunworldonline/common/swol-siteindex.html#webperf
• Web server security-related stories in the SunWorld Topical Index:
  http://www.sunworld.com/sunworldonline/common/swol-siteindex.html#websec

• The SunWorld Topical Index -- a comprehensive listing of all SunWorld articles by subject:
  http://www.sunworld.com/common/swol-siteindex.html
• Visit sunWHERE -- launchpad to hundreds of online resources for Sun users:
  http://www.sunworld.com/sunwhere.html
• Explore SunWorld's back issues:
  http://www.sunworld.com/common/swol-backissues.html
• IDG.net, your one-stop IT resource:
  http://www.idg.net

About the author
R. Allen Wyke has developed intranet pages and Internet sites for several leading companies, and often speaks on the topic of HTML. His writing credentials include coauthoring Pure JavaScript, The Perl 5 Programmer's Reference, and The Official Netscape Navigator 4 Book, as well as contributing to The HTML 4 Programmer's Reference and HTML Publishing for the Internet, 2nd Edition.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-08-1999/swol-08-webmaster.html
Last modified: