Introduction to Client-Side Scripting
- Introduction to Client-Side Scripting
- Scripts in Web Applications
- The Role of Client-Side Scripting
- Capabilities and Limitations of Client-Side Scripting
Like this article? We recommend
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.