All Categories :
JavaScript
Chapter 1
What Is JavaScript?
CONTENTS
JavaScript is a lightweight object-based scripting language created
by Netscape Communications Corporation for developing Internet
applications. JavaScript is lightweight in that there isn't a
great deal to learn and you can be productive with it very quickly,
in contrast to much more complex languages such as Java. As a
scripting language, JavaScript is meant to tell an application
what to do. Unlike languages used to create applications, it cannot
do anything without the application.
You can develop server applications or client applications with
JavaScript. In this book, the term "server" refers to
the computer where your Web pages reside. The term "client"
refers to the browser application that loads and displays your
Web pages. This book focuses on teaching you to create client
applications with JavaScript-specifically, documents (Web pages)
on the World Wide Web.
You can embed JavaScript statements in Web pages, which are written
in HTML (Hypertext Markup Language). JavaScript is an extension
to HTML that lets you create more sophisticated Web pages than
you ever could with HTML alone. To appreciate this, it helps to
know a little history.
Strictly speaking, HTML is a Standard Generalized Markup Language
(SGML), Document Type Definition (DTD). An SGML document has three
parts. The first part defines the character set to be used and
tells which characters in that set distinguish text from markup
tags. Markup tags specify how the viewer application, or browser,
should present the text to the user. The second part of an SGML
document specifies the document type and states which markup tags
are legal. The third part of an SGML document, called the document
instance, contains the actual text and markup tags. Because there
is no requirement that the three parts of an SGML document reside
in the same physical file, we can concentrate on the document
instance. The Web pages you create are document instances.
Most HTML browsers assume a common definition about the character
set used, and about which characters distinguish text from markup
tags. They also generally agree about a core set of legal markup
tags. They then diverge on which additional new markup tags to
permit.
HTML 1.0 refers to the original set of markup tags. HTML 1.0 is
so limited that a browser that restricted HTML documents to HTML
1.0 would be a museum piece.
HTML 2.0 includes a more generous set of markup tags than HTML
1.0; in particular, it allows markup tags that define user input
fields. As of this writing, HTML 2.0 defines the de facto common
core of markup tags. You can create a relatively sophisticated
Web page with HTML 2.0 markup tags.
HTML 3.0, still in the process of standardization, adds additional
markup tags to those defined in HTML 2.0, such as tags to define
tables, figures, and mathematical equations. HTML 3.0 expands
some tags to include more functionality, such as centering text
or images in the browser, and adding background colors and images.
NHTML, a nickname for Netscape's extension of HTML 2.0, is another
set of markup tags that goes beyond those defined in HTML 2.0.
Netscape, like other developers of cutting edge Web browsers,
is trying to influence the development of the HTML 3.0 standard,
and has developed extensions of its own. At the same time, Netscape
is making an effort to conform to the evolving HTML 3.0 specification.
Furthermore, Netscape continues to support markup tags that the
draft HTML 3.0 specification has declared obsolete.
Netscape's browser, Netscape Navigator, is not precisely HTML
3.0-compliant. The best way to find out whether Netscape Navigator
supports a particular markup tag is to get the latest version
and try a document containing the tag.
Why NHTML isn't proper SGML
Formally, a Web page is the third part of an SGML DTD, and as
such, should conform to the SGML DTD specification.
A few features of NHTML do not conform to the rules of the SGML
DTD specification. If browsers actually treated a Web page as
the third part of an SGML DTD, this would be a problem. However,
browsers typically accept a certain hard-coded level of HTML-typically
HTML 2.0 with some HTML 3.0 extensions and some NHTML extensions-and
ignore markup tags that they do not recognize.
Where this nonconformity does present a problem is in writing
tools that validate Web pages. These tools typically use an SGML
parser, and they require a page to be part of a properly conforming
SGML DTD for the level of HTML they check.
Should you validate your Web pages? I think so, although as of
this writing, it's not a viable option for JavaScript pages. So
far, no one has come up with a validation tool that recognizes
and validates the syntax of JavaScript. But count on it; someone
will. And when they do, try it on your pages. Validation tools
have saved me countless hours of headaches trying to figure out
why my HTML code wasn't working correctly.
Just for the record, here are the nonconforming parts of NHTML:
- NHTML makes liberal use of the % character. It's used to specify
that certain entities occupy a fixed percentage of the window's
real estate, or to specify scaling on images. The problem with
this is that the % character is a reserved character in the SGML
specification for declaring parameter entities in a DTD. It does
not belong in a Web page. There is no workaround to achieve the
same effect. An SGML parser-based validation tool will not accept
pages with % characters in the attributes.
- NHTML allows the BORDER attribute to be specified in two ways:
<TABLE BORDER>
and
<TABLE BORDER="1">
The SGML DTD specification does not allow an attribute to
be specified in two entirely different fashions like this. While
a grammatically correct SGML DTD cannot handle both forms simultaneously,
a grammatically correct SGML DTD can handle either form. Since
BORDER alone means the same thing as BORDER="1", BORDER
alone is redundant, and you can write a DTD that says the BORDER
attribute always takes a numeric argument. From the standpoint
of making your pages clear and easy to maintain, it's always a
good idea to state the border size explicitly.
- SGML parsers will not accept tags like <FONT SIZE=+3>
and <FONT SIZE=-2>. Fortunately, this one is easy to work
around: Place the value in double quotes, like this:
<FONT SIZE="+3">
and
<FONT SIZE="-2">
- Color attributes specified as six-digit hexadecimal values
will not pass an SGML parser if written like this:
<BODY BGCOLOR=#123456>
As with the incremented or decremented font sizes, you can
fix this problem by placing the offending value inside double
quotes.
<BODY BGCOLOR="#123456">
Netscape began working on a scripting language called LiveScript,
which quickly evolved into what is now JavaScript. Although JavaScript
and Java are not the same thing, Netscape intends JavaScript to
tie into Java; hence the name change. Netscape and Sun Microsystems
(the developers of Java) are working closely on the development
of the two languages. There are few other major differences between
LiveScript and JavaScript, the biggest being that LiveScript was
case-insensitive and JavaScript is case-sensitive.
JavaScript can provide a high degree of user interaction like
some other systems, including CGI and Java.
The Common Gateway Interface (CGI) provides a mechanism for a
program on the server to interact with the client's browser. You
can use any language to write CGI programs, and CGI programs may
be interpreted (PERL scripts, for instance) or compiled (C or
C++). One popular use of CGI is in hit counters-programs that
modify the page to show how many times that page has been visited.
Another popular use of CGI is in form handling, where a program
on the server reads the data from the user input fields and does
some work based on that data.
JavaScript, which does its work in the client's browser, cannot
entirely replace CGI. For instance, a hit counter has to update
a file on the server so it can remember how many times the page
has been visited by all visitors. That's a little difficult for
JavaScript, but a JavaScript Web page can keep track of
how many times a given visitor has visited the page. So can CGI,
but only if given an endless supply of disk space on the server.
JavaScript can do a lot of the same things CGI can do, and it
can often do them much more efficiently. For example, JavaScript
can do form validation more efficiently than CGI. When a non-JavaScript
page has user input fields, it sends all the field values to a
CGI server application. The CGI application then has to figure
out whether the data in each field makes sense before doing something
with the data. A JavaScript page, however, can validate the data
entered before it is sent to the server. If the data is invalid,
JavaScript can block transmission to the server. Because all of
this work is performed on the client side, JavaScript does not
waste bandwidth transmitting bad data and then receiving an error
page from the server.
JavaScript can also replace some of the animation and page-reloading
functionality of CGI. To perform animation and page-reloading,
CGI provides mechanisms called "server push" and "client
pull." With server push, the Web page server maintains a
connection between the client (the browser) and server. Server
push restricts the number of simultaneous connections the Web
page server can maintain-a popular page using server push will
frequently reward potential visits with a "sorry, not now,
try later" message. Client pull, on the other hand, involves
the client frequently re-establishing its connection to the server,
artificially adding to the traffic at the server. You can use
JavaScript to create dynamic documents that would have required
either server push or client pull in CGI, but that involve no
additional traffic or long, drawn-out connections between the
client and the server.
JavaScript is independent of the server platform, the hardware
and software that your server uses. CGI has to be written in a
language that your server platform supports. No single language
is supported by all server platforms. If your Web pages rely on
CGI, what happens if the company that provides your server changes
platforms? What happens if they go bankrupt and you have to take
your pages and their CGI applications to another server?
Finally, not all Web space providers allow Web pages to use CGI.
CGI requires that the program be executed on the server, but some
Web space providers are nervous about the possible side effects
of badly written or maliciously written CGI programs being executed
on their machines. Some providers only allow the use of a limited
set of applications. Many providers do not support server push
CGI. JavaScript running on the client browser is perfectly safe
to the server, and affords you, the creator of the JavaScript
document, much greater flexibility in how your document interacts
with the reader.
Many people confuse JavaScript with Java, which is a programming
language developed by Sun Microsystems, Inc. Each has its own
Usenet newsgroup, yet people frequently post questions about Java
to the JavaScript newsgroup, and vice versa.
Java is a programming language and JavaScript is a scripting language.
Java programs are compiled on the server. You can write stand-alone
programs in Java. Scripts written in JavaScript are interpreted
by the browser. You cannot write stand-alone programs in JavaScript-you
need a browser to interpret JavaScript.
Java is object-oriented. It employs classes and inheritance. It
provides encapsulation of data. JavaScript is object-based. There
are no classes. There is no inheritance. Data within objects is
readily accessible.
Java is compiled into "applets" that are accessed from
HTML pages. JavaScript is embedded in HTML.
Java requires that data types be strongly typed (if a function
expects one of its arguments to be a number, the function will
not accept a character string). JavaScript is loosely typed. JavaScript
has numbers, character strings, and Booleans (logical yes/no,
true/false, on/off data) and freely interchanges them.
Java can be used to create very powerful applications. JavaScript
scripts cannot really do all the neat things that Java applets
can. On the other hand, it is much more difficult to write programs
in Java than it is to write scripts in JavaScript.
JavaScript, as described in this book, is supported by Netscape
Navigator 2.01 and later releases. It is supported on several
architectures, as you can see in Table 1.1.
Table 1.1: Netscape Platforms
Architecture | Operating System
|
Windows | Windows 3.1
Windows 3.11
Windows NT 3.5 and later
Windows 95
|
Macintosh | MacOS |
UNIX | DEC Alpha OSF/1 2.0 and later
HP-UX 9.03
IBM RS/6000 AIX 3.2
Irix
Sun Sparc Solaris 2.3
Sun Sparc Solaris 2.4
Sun Sparc SunOS 4.1.3
BSDI
Linux 1.1.59 and later
|

Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.