What separates a Web page from an application is rich, two-way communication between the user and the site. Scott Loban delves into client-side scripting, a key technology for providing greater interactivity and pizzazz to Web applications.

Like this article? We recommend

Like this article? We recommend

The previous article in this series concluded our introduction to
Cascading Style Sheets. This article begins a look at client-side scripting, the
keystone technology for providing greater interactivity, customizability, and
pizzazz to Web applications.

Interactive Web Applications

What separates a Web page from an application is rich, two-way communication
between the user and the site. An application accepts data from the user and
dynamically tailors its output based on this input. While HTML itself does offer
a few built-in elements and features that enable Web developers to implement
interactive functionality in a Web page, these features revolve around form
submission, and do not, by themselves, offer much opportunity for creating
exciting Web applications.

On the other end of the spectrum from HTML's standard text box and radio
button, Java and ActiveX both offer ways to embed small, full-featured programs
in the browser window, providing a richer user experience (see sidebar entitled
"An Alternative: Embedded Objects on the Client"). Unfortunately, this
power comes at the expense of relatively complex programming and heavy
requirements for memory and processing power on the client.

Client-side scripts occupy a middle ground between these two extremes,
offering a Web application with more functionality than pure HTML, but with less
complexity and a lower processing load than embedded Java or ActiveX controls.
The next few articles in this series explore the role of client-side scripting
in Web applications, introduce some of its major components, and present a
number of coding style guidelines for client-side scripting.

An Alternative: Embedded Objects on the Client

As an alternative to client-side scripting, modern browsers also support the
capability to embed references to precompiled software components in a Web page.
The two primary technologies for this are Java and ActiveX. In both cases, the
browser downloads the component to the client computer, where the underlying
operating systemor, in the case of Java applets, a runtime environment
called the Java virtual machineexecutes the code.

The benefits of this approach include the capability to implement richer
functionality than that offered by client-side scripting alone. This is because
the components are developed with full-blown programming languages, and the
environment in which the components run offers much richer resources than the
Web browser alone offers to client-side scripts. An additional benefit is that
the compiled nature of the components means that the source code is never
downloaded to the client. This makes it far easier to protect the
developer's intellectual property. Finally, these components offer
increased cross-browser compatibility. The same component should work the
same way on any manufacturer's browser.

On the other hand, this approach suffers from several drawbacks. First, while
it was noted that embedded components offer increased cross-browser
compatibility, they can exhibit problems with cross-platform
compatibility. The same component often works quite differently in the same
brand or version of browser running on different operating system architectures.
In addition, this approach is noted for having performance issues. The
additional overhead associated with running components embedded in a Web page
means that the code might run more slowly.

Versioning can also be problematic. The components can run into mismatches if
the user has previously downloaded an earlier version of the component or one of
its dependencies, or if an entirely different product has installed a different
version of the same component. Finally, and possibly most serious, are the
security implications of embedded components. Particularly a problem with
ActiveX technology, there have been many documented cases in which the system
has failed to limit access to system-level resources appropriately. Unscrupulous
developers could exploit this to violate system security.