JavaScript

What Is JavaScript?
When JavaScript first appeared in 1995, its main purpose was to handle some of the input validation
that had previously been left to server-side languages such as Perl. Prior to that time, a round
trip to the server was needed to determine if a required field had been left blank or an entered
value was invalid. Netscape Navigator sought to change that with the introduction of JavaScript.
The capability to handle some basic validation on the client was an exciting new feature at a time
when use of telephone modems (operating at 28.8 kbps) was widespread. Such slow speeds

turned every trip to the server into an exercise in patience.
Since that time, JavaScript has grown into an important feature of every major Web browser on
the market. No longer bound to simple data validation, JavaScript now interacts with nearly all
aspects of the browser window and its contents. Even Microsoft, with its own client-side scripting
language called VBScript, ended up including its own JavaScript implementation in Internet
Explorer from its very earliest version.
In this chapter, you will learn how and why JavaScript came about, from its humble beginnings to
its modern-day, feature-packed implementations. To be able to use JavaScript to its full potential, it
is important to understand its nature, history, and limitations. Specifically, this chapter examines:
❑ The origins of JavaScript and client-side scripting
❑ The different parts of the JavaScript language
❑ The standards related to JavaScript
❑ JavaScript support in popular Web browsers
A Short History
Around 1992, a company called Nombas began developing an embedded scripting language
called C-minus-minus (Cmm for short). The idea behind Cmm was simple: a scripting language
powerful enough to replace macros, but still similar enough to C (and C++) that developers could learn
it quickly. This scripting language was packaged in a shareware product called CEnvi, which first
exposed the power of such languages to developers. Nombas eventually changed the name Cmm to
ScriptEase because the latter sounded “too negative” and the letter C “frightened people” (http://
www.nombas.com/us/scripting/history.htm). ScriptEase is now the driving force behind Nombas
products. When the popularity of Netscape Navigator started peaking, Nombas developed a version of
CEnvi that could be embedded into Web pages. These early experiments were called Espresso Pages, and
they represented the first client-side scripting language used on the World Wide Web. Little did Nombas
know that its ideas would become an important foundation for the Internet.
As Web surfing gained popularity, a gradual demand for client-side scripting languages developed. At
the time, most Internet users were connecting over a 28.8 kbps modem even though Web pages were
growing in size and complexity. Adding to users’ pain was the large number of round-trips to the server
required for simple form validation. Imagine filling out a form, clicking the Submit button, waiting 30
seconds for processing, and then being met with a message telling you that you forgot to complete a
required field. Netscape, at that time on the cutting edge of technological innovation, began seriously
considering the development of a client-side scripting language to handle simple processing.
Brendan Eich, who worked for Netscape at the time, began developing a scripting language called
LiveScript for the upcoming release of Netscape Navigator 2.0 in 1995, with the intention of using it both
in the browser and on the server (where it was to be called LiveWire). Netscape entered into a development
alliance with Sun Microsystems to complete the implementation of LiveScript in time for release.
Just before Netscape Navigator 2.0 was officially released, Netscape changed the name to JavaScript in
order to capitalize on Java as a new Internet buzzword. Netscape’s gamble paid off and JavaScript
became a must-have from that point on.
Because JavaScript 1.0 was such a hit, Netscape released version 1.1 in Netscape Navigator 3.0. Right
around that time, Microsoft decided to throw its hat into the ring and released Internet Explorer 3.0 with
a JavaScript-clone called JScript (so-called in order to avoid any possible licensing issues with Netscape).
This major step for Microsoft into the realm of Web browsers is now a date that lives in infamy for
Netscape, but it also represented a major step in the development of JavaScript as a language.
After Microsoft threw its hat into the ring, three different JavaScript versions were floating around:
JavaScript in Netscape Navigator, JScript in Internet Explorer, and CEnvi in ScriptEase. Unlike C and
many other programming languages, JavaScript had no standards governing its syntax or features, and
the three different versions only highlighted this problem. With industry fears mounting, it was decided
that the language must be standardized.
In 1997, JavaScript 1.1 was submitted to the European Computer Manufacturers Association (ECMA) as a
proposal. Technical Committee #39 (TC39) was assigned to “standardize the syntax and semantics of a general
purpose, cross-platform, vendor-neutral scripting language” (http://www.ecma-international
.org/memento/TC39.htm). Made up of programmers from Netscape, Sun, Microsoft, Borland, and other
companies with interest in the future of scripting, TC39 met for months to hammer out ECMA-262, a standard
defining a new scripting language named ECMAScript.
The following year, the International Organization for Standardization and International Electrotechnical
Commission (ISO/IEC) also adopted ECMAScript as a standard (ISO/IEC-16262). Since that time, Web
browsers have tried, with varying degrees of success and failure, to use ECMAScript as a basis for their
JavaScript implementations.
JavaScript Implementations
Although ECMAScript is an important standard, it is not the only part of JavaScript, and certainly not
the only part that has been standardized. Indeed, a complete JavaScript implementation is made up of
three distinct parts (see Figure 1-1):
❑ The Core (ECMAScript)
❑ The Document Object Model (DOM)
❑ The Browser Object Model (BOM)
ECMAScript
ECMAScript doesn’t have ties to any browser in particular and, actually, has no methods for user input
or output to speak of. (It is not unlike languages such as C, which rely on external libraries to accomplish
such tasks.) So what is ECMAScript? ECMA-262 (p. 2) describes it like this:
“ECMAScript can provide core scripting capabilities for a variety of host environments, and therefore
the core scripting language is specified...apart from any particular host environment.”
AWeb browser is considered a host environment for ECMAScript, but it is not the only host environment.
Indeed, numerous other environments (such as Nombas’s ScriptEase and Macromedia’s ActionScript,
used in both Flash and Director MX) can host ECMAScript implementations. So what does ECMAScript
specify outside of a browser? To put it simply, ECMAScript describes the following:
❑ Syntax
❑ Types
❑ Statements
❑ Keywords
❑ Reserved Words
❑ Operators
❑ Objects
ECMAScript is simply a description, defining all the properties, methods, and objects of a scripting language.
Other languages implement ECMAScript, as JavaScript does (see Figure 1-2), as the baseline for
functionality.
JavaScript
ECMAScript DOM BOM
Each browser has its own implementation of the ECMAScript interface, which is then extended to contain
the DOM and BOM (discussed in the following sections). There are other languages that also implement
and extend ECMAScript such as Windows Scripting Host (WSH), ActionScript in Macromedia
Flash and Director, and Nombas ScriptEase.