JavaScript Editor JavaScript Debugger     JavaScript Editor 

Team LiB
Previous Section Next Section

History and Use of JavaScript

Knowledge of JavaScript’s past actually leads to a great deal of understanding about its quirks, challenges, and even its potential role as a first class Web technology. For example, even the name JavaScript itself can be confusing unless you consider history since, despite the similarity in name, JavaScript has nothing to do with Java. Netscape initially introduced the language under the name LiveScript in an early beta release of Navigator 2.0 in 1995, and the focus of the language was initially for form validation. Most likely the language was renamed JavaScript because of the industry’s fascination with all things Java at the time as well as the potential for the two languages to be integrated together to build Web applications. Unfortunately, because of including the word “Java” in its name, JavaScript is often thought of as some reduced scripting form of Java. In reality the language as it stands today is only vaguely similar to Java, and syntactically often shares more in common with languages such as C, Perl, and Python.

While the name of the language has led to some confusion by some of its users, it has been widely adopted by browser vendors. After Netscape introduced JavaScript in version 2.0 of their browser, Microsoft introduced a clone of JavaScript called JScript in Internet Explorer 3.0. Opera also introduced JavaScript support during the 3.x generation of its browser. Many other browsers also support various flavors of JavaScript. As time has gone by, each of the major browser vendors has made their own extensions to the language and the browsers have each supported various versions of JavaScript or JScript. Table 1-1 details the common browsers that support a JavaScript language. The various features of each version of JavaScript are discussed throughout the book, and Appendix B provides information on the support of various features in each version of the language.

Table 1-1: Browser Versions and JavaScript Support

Browser Version

JavaScript Support

Netscape 2.x


Netscape 3.x


Netscape 4.0–4.05


Netscape 4.06–4.08, 4.5x, 4.6x, 4.7x


Netscape 6.x,7.x


Mozilla variants


Internet Explorer 3.0

Jscript 1.0

Internet Explorer 4.0

Jscript 3.0

Internet Explorer 5.0

Jscript 5.0

Internet Explorer 5.5

Jscript 5.5

Internet Explorer 6

Jscript 5.6

Because the specification of JavaScript is changing rapidly and cross-platform support is not consistent, you should be very careful with your use of JavaScript with browsers. Since different levels of JavaScript support different constructs, programmers should be careful to create conditional code to handle browser and language variations. Much of the book will deal with such issues, but a concentrated discussion can be found in Chapter 23.

Because of the cross-browser JavaScript nightmare inflicted on programmers, eventually a standard form of JavaScript called ECMAScript (pronounced eck-ma-script) was specified. Version 3 is the latest edition of ECMAScript. While most of the latest browsers have full or close to full support for ECMAScript, the name itself has really yet to catch on with the public, and most programmers tend to refer to the language, regardless of flavor, as simply JavaScript.


JavaScript 2.0 and ECMAScript version 4 are both being slowly pushed through the standards process. Given the fall of Netscape, it is unclear what is going to happen to these versions of the language, and so far the browser vendors are far from implementing the language. However, brief mentions of important differences will be presented throughout the book where appropriate.

Even with the rise of ECMAScript, JavaScript can still be challenging to use. ECMAScript primarily is concerned with defining core language features such as flow control statements (for example, if, for, while, and so on) and data types. But JavaScript also generally can access a common set of objects related to its execution environment—most commonly, a browser. These objects—such as the window, navigator, history, and screen—are not a part of the ECMAScript specification, and are collectively referred to as the traditional Browser Object Model or BOM. The fact that all the browser versions tend to have similar but subtly different sets of objects making up their BOMs causes mass confusion and widespread browser incompatibility in Web pages. The BOM finally reached its worst degree of incompatibility with the 4.x generation of browsers introducing the idea of Dynamic HTML, or DHTML. In reality there is no such thing, technically, as DHTML. The idea came from marketing terms for the 4.x generation browsers and was used to characterize the dynamic effects that arise from using HTML, CSS, and JavaScript on a page. If you are talking about DHTML, you are talking about the intersection of these technologies and not some all-new technology separate from JavaScript.

Fortunately, the W3C has defined standard objects with which to access Web page components such as HTML elements and their enclosed text fragments, CSS properties, and even XML elements. In doing so, they’ve tried to end the nightmare of DHTML incompatibilities. Their specification is called the Document Object Model, or DOM for short. It defines a standard way to manipulate page elements in markup languages and style sheets providing for all the effects possible with DHTML without the major incompatibilities. However, there is some cross-over between what is part of the traditional object model and what is DOM, and differences in DOM implementations abound. Fortunately, the newer browsers have begun to iron out many incompatibilities and the interaction between JavaScript and page objects is finally starting to become well defined. More information on the DOM can be found at as well as in Chapter 10.

When taken together, core JavaScript as specified by ECMAScript, browser objects, and document objects will provide all the facilities generally required by a JavaScript programmer. Unfortunately, except for the core language, all the various objects available seem to vary from browser to browser and version to version, making correct cross-browser coding a real challenge! A good portion of this book will be spent trying to iron out these difficulties.

As we have seen, study of the evolution of JavaScript can be critical for mastering its use, as it explains some of the design motivations behind its changes. While JavaScript is quite powerful as a client-side technology, like all languages, it is better at some types of applications than others. Some of these common uses of JavaScript include

JavaScript does have its limits. It does not support robust error-handling features, strong typing, or facilities useful for building large-scale applications. Yet despite its flaws and many of the misunderstandings surrounding the language, it has succeeded wildly. Some might say, if you consider all Web developers who have touched the language at one point or another, it is one of the most popular and widely used—though misunderstood—languages on the planet. JavaScript’s popularity is growing even beyond the Web, and we see its core in the form of ECMAScript being used in embedded systems and within applications such as Dreamweaver as an internal automation and scripting language. ECMAScript has also spawned numerous related languages, most notably ActionScript in Flash. Much of the user interface of the Mozilla and modern Netscape Web browsers is implemented with JavaScript. JavaScript is no longer relegated to trivial simple rollover effects and form checking; it is a powerful and widely used language. As such, JavaScript should be studied rigorously, just like any programming language, and that is what we will do starting in the next chapter.

Team LiB
Previous Section Next Section

JavaScript Editor JavaScript Debugger     JavaScript Editor