Exposing the Browser API with Client-side Scripting
July 26, 1999
As you might imagine, adding all these add-on features to the web
browsers began to cause problems. Specifically, distributing
functionality in the form of Active-X controls, plug-ins, or Java
applets could mean unacceptable download times for users.
In some cases, users would be willing to wait. Specifically, if
the applications they required demanded the rich texture provided
by plug in technologies, users would accommodate download times.
However, in other cases, users wanted a less complex solution.
Granted, the solution should be more complex than HTML
forms, but
not necessarily as complex as Java.
Enter JavaScript.
Netscape 2.0 introduced JavaScript (initially LiveScript), a
distant cousin of the Java language, as a means for achieving
some special effects in the web browser without actually having
to resort to a plug-in technology.
|
NOTE: Soon after the release of JavaScript by Netscape, Microsoft
released their own semi-compatible version called JScript in
Internet Explorer 3.0. JScript, however eventually lost much of
its appeal after Microsoft released VBScript that leveraged the
Visual Basic programming language to do the same thing as
JavaScript.
VBScript would fast become Microsoft's preferred Web Language
however because most developers like to keep their applications
cross browser compatible, VBScript has receded to a large degree
onto the server side for ASP which we will talk about later.
Most client-side development is done in JavaScript.
|
Actually, to tell you the truth, JavaScript is a bit of a misnomer
(or a marketing ploy) because though JavaScript is indeed a
scripting language (browsers include a JavaScript interpreter),
it actually is very different from Java. Whereas Java is a
self contained programming language capable of full featured
application development on its own, JavaScript is built as a
programming glue that developers can use to tie other technologies
(HTML or the browser itself) together within the scope of the web
browser. That is, you would rarely say that you had finished
work on a JavaScript application, but you might say that you had
added some JavaScript functionality to your web page.
JavaScript is not so much about adding new functionality as it
is about tweaking existing functionality to make it seem more
cool.
The most important thing to understand about JavaScript is that
it exposed much of the browser API to developers. Specifically,
the browser and many of the widgets inside the browser could be
talked to, listened to and controlled.
Developers quickly began to use JavaScript for such purposes as
animation,
accessing the bookmarks and history, event handling
(like mouse over effects such as when a graphical image button
lights up when the mouse crosses over it), form field validation
(such as when you make sure the user has entered in data for all
the required fields before you let them submit the HTML form to
a web server), and the spawning of event dialogs and new windows.
What was nice was that JavaScript was written for the common
person and required little programming background
to master. Web designers could add a great deal more
functionality and bells and whistles to their existing HTML pages
without needing to resort to server-side programming like
CGI.
JavaScript has gone through several iterations of versioning and
though there are still compatibility problems between IE and
Netscape, the standard features of the language have been nailed
down pretty well.
Yet, almost as soon as it was released, developers realized that
exposing the browser API was not enough. Client-side scripting
languages, they realized, had the potential to be incredibly
powerful if they were only given a bit more oomph. Specifically,
they need to have the document API exposed.
Enter Dynamic HTML....
Extending the Browser with Plug-ins
Introduction to the Web Application Development Environment (Tools)
Exposing the Document with the DOM and dHTML
|
