Fri, May 31, 2019 4:51:16 PM
designers of the Web did not foresee how rapidly this bandwidth would be exhausted for the <br/>
kinds of applications people developed. For example, any sort of dynamic graphing is nearly <br/>
impossible to perform with consistency because a Graphics Interchange Format (GIF) file <br/>
must be created and moved from the server to the client for each version of the graph. In <br/>
addition, you�ve no doubt experienced the process of data validation for a Web input form. <br/>
You press the submit button on a page; the data is shipped back to the server; the server <br/>
starts a CGI program that discovers an error, formats an HTML page informing you of the <br/>
error, and then sends the page back to you; you must then back up a page and try again. Not <br/>
only is this slow, it�s inelegant. <br/>
The solution is client-side programming. Most desktop computers that run Web browsers are <br/>
powerful engines capable of doing vast work, and with the original static HTML approach <br/>
they are sitting there, just idly waiting for the server to dish up the next page. Client-side <br/>
programming means that the Web browser is harnessed to do whatever work it can, and the <br/>
result for the user is a much speedier and more interactive experience at your Web site. <br/>
The problem with discussions of client-side programming is that they aren�t very different <br/>
from discussions of programming in general. The parameters are almost the same, but the <br/>
platform is different; a Web browser is like a limited operating system. In the end, you must <br/>
still program, and this accounts for the dizzying array of problems and solutions produced by <br/>
client-side programming. The rest of this section provides an overview of the issues and <br/>
approaches in client-side programming. <br/>
Plug-ins <br/>
One of the most significant steps forward in client-side programming is the development of <br/>
the plug-in. This is a way for a programmer to add new functionality to the browser by <br/>
downloading a piece of code that plugs itself into the appropriate spot in the browser. It tells <br/>
the browser, �From now on you can perform this new activity.� (You need to download the <br/>
plug-in only once.) Some fast and powerful behavior is added to browsers via plug-ins, but <br/>
writing a plug-in is not a trivial task, and isn�t something you�d want to do as part of the <br/>
process of building a particular site. The value of the plug-in for client-side programming is <br/>
that it allows an expert programmer to develop extensions and add those extensions to a <br/>
browser without the permission of the browser manufacturer. Thus, plug-ins provide a �back <br/>
door� that allows the creation of new client-side programming languages (although not all <br/>
languages are implemented as plug-ins). <br/>
Scripting languages <br/>
Plug-ins resulted in the development of browser scripting languages. With a scripting <br/>
language, you embed the source code for your client-side program directly into the HTML <br/>
page, and the plug-in that interprets that language is automatically activated while the HTML <br/>
page is being displayed. Scripting languages tend to be reasonably easy to understand and, <br/>
because they are simply text that is part of an HTML page, they load very quickly as part of <br/>
the single server hit required to procure that page. The trade-off is that your code is exposed <br/>
for everyone to see (and steal). Generally, however, you aren�t doing amazingly sophisticated <br/>
things with scripting languages, so this is not too much of a hardship. <br/>
One scripting language that you can expect a Web browser to support without a plug-in is <br/>
JavaScript (this has only a passing resemblance to Java and you�ll have to climb an additional <br/>
learning curve to use it. It was named that way just to grab some of Java�s marketing <br/>
momentum). Unfortunately, most Web browsers originally implemented JavaScript in a <br/>
different way from the other Web browsers, and even from other versions of themselves. The <br/>
standardization of JavaScript in the form of ECMAScript has helped, but it has taken a long <br/>
time for the various browsers to catch up (and it didn�t help that Microsoft was pushing its <br/>
own agenda in the form of VBScript, which also had vague similarities to JavaScript). In <br/>
general, you must program in a kind of least-common-denominator form of JavaScript in <br/>
Introduction to Objects 35�<br/>
order to be able to run on all browsers. Dealing with errors and debugging JavaScript can <br/>
only be described as a mess. As proof of its difficulty, only recently has anyone created a truly <br/>
complex piece of JavaScript (Google, in GMail), and that required excessive dedication and <br/>
expertise. <br/>
This points out that the scripting languages used inside Web browsers are really intended to <br/>
solve specific types of problems, primarily the creation of richer and more interactive <br/>
graphical user interfaces (GUIs). However, a scripting language might solve 80 percent of the <br/>
problems encountered in client-side programming. Your problems might very well fit <br/>
completely within that 80 percent, and since scripting languages can allow easier and faster <br/>
development, you should probably consider a scripting language before looking at a more <br/>
involved solution such as Java programming. <br/>
Java <br/>
If a scripting language can solve 80 percent of the client-side programming problems, what <br/>
about the other 20 percent�the �really hard stuff�? Java is a popular solution for this. Not <br/>
only is it a powerful programming language built to be secure, cross-platform, and <br/>
international, but Java is being continually extended to provide language features and <br/>
libraries that elegantly handle problems that are difficult in traditional programming <br/>
languages, such as concurrency, database access, network programming, and distributed <br/>
computing. Java allows client-side programming via the applet and with Java Web Start. <br/>
An applet is a mini-program that will run only under a Web browser. The applet is <br/>
downloaded automatically as part of a Web page (just as, for example, a graphic is <br/>
automatically downloaded). When the applet is activated, it executes a program. This is part <br/>
of its beauty�it provides you with a way to automatically distribute the client software from <br/>
the server at the time the user needs the client software, and no sooner. The user gets the <br/>
latest version of the client software without fail and without difficult reinstallation. Because <br/>
of the way Java is designed, the programmer needs to create only a single program, and that <br/>
program automatically works with all computers that have browsers with built-in Java <br/>
interpreters. (This safely includes the vast majority of machines.) Since Java is a full-fledged <br/>
programming language, you can do as much work as possible on the client before and after <br/>
making requests of the server. For example, you won�t need to send a request form across the <br/>
Internet to discover that you�ve gotten a date or some other parameter wrong, and your client <br/>
computer can quickly do the work of plotting data instead of waiting for the server to make a <br/>
plot and ship a graphic image back to you. Not only do you get the immediate win of speed <br/>
and responsiveness, but the general network traffic and load on servers can be reduced, <br/>
preventing the entire Internet from slowing down. <br/>
Alternatives <br/>
To be honest, Java applets have not particularly lived up to their initial fanfare. When Java <br/>
first appeared, what everyone seemed most excited about was applets, because these would <br/>
finally allow serious client-side programmability, to increase responsiveness and decrease <br/>
bandwidth requirements for Internet-based applications. People envisioned vast <br/>
possibilities. <br/>
Indeed, you can find some very clever applets on the Web. But the overwhelming move to <br/>
applets never happened. The biggest problem was probably that the 10 MB download <br/>
necessary to install the Java Runtime Environment (JRE) was too scary for the average user. <br/>
The fact that Microsoft chose not to include the JRE with Internet Explorer may have sealed <br/>
its fate. In any event, Java applets didn�t happen on a large scale. <br/>
Nonetheless, applets and Java Web Start applications are still valuable in some situations. <br/>
Anytime you have control over user machines, for example within a corporation, it is <br/>
36 Venkata Pilaka Venkata Pilaka <br/>
kinds of applications people developed. For example, any sort of dynamic graphing is nearly <br/>
impossible to perform with consistency because a Graphics Interchange Format (GIF) file <br/>
must be created and moved from the server to the client for each version of the graph. In <br/>
addition, you�ve no doubt experienced the process of data validation for a Web input form. <br/>
You press the submit button on a page; the data is shipped back to the server; the server <br/>
starts a CGI program that discovers an error, formats an HTML page informing you of the <br/>
error, and then sends the page back to you; you must then back up a page and try again. Not <br/>
only is this slow, it�s inelegant. <br/>
The solution is client-side programming. Most desktop computers that run Web browsers are <br/>
powerful engines capable of doing vast work, and with the original static HTML approach <br/>
they are sitting there, just idly waiting for the server to dish up the next page. Client-side <br/>
programming means that the Web browser is harnessed to do whatever work it can, and the <br/>
result for the user is a much speedier and more interactive experience at your Web site. <br/>
The problem with discussions of client-side programming is that they aren�t very different <br/>
from discussions of programming in general. The parameters are almost the same, but the <br/>
platform is different; a Web browser is like a limited operating system. In the end, you must <br/>
still program, and this accounts for the dizzying array of problems and solutions produced by <br/>
client-side programming. The rest of this section provides an overview of the issues and <br/>
approaches in client-side programming. <br/>
Plug-ins <br/>
One of the most significant steps forward in client-side programming is the development of <br/>
the plug-in. This is a way for a programmer to add new functionality to the browser by <br/>
downloading a piece of code that plugs itself into the appropriate spot in the browser. It tells <br/>
the browser, �From now on you can perform this new activity.� (You need to download the <br/>
plug-in only once.) Some fast and powerful behavior is added to browsers via plug-ins, but <br/>
writing a plug-in is not a trivial task, and isn�t something you�d want to do as part of the <br/>
process of building a particular site. The value of the plug-in for client-side programming is <br/>
that it allows an expert programmer to develop extensions and add those extensions to a <br/>
browser without the permission of the browser manufacturer. Thus, plug-ins provide a �back <br/>
door� that allows the creation of new client-side programming languages (although not all <br/>
languages are implemented as plug-ins). <br/>
Scripting languages <br/>
Plug-ins resulted in the development of browser scripting languages. With a scripting <br/>
language, you embed the source code for your client-side program directly into the HTML <br/>
page, and the plug-in that interprets that language is automatically activated while the HTML <br/>
page is being displayed. Scripting languages tend to be reasonably easy to understand and, <br/>
because they are simply text that is part of an HTML page, they load very quickly as part of <br/>
the single server hit required to procure that page. The trade-off is that your code is exposed <br/>
for everyone to see (and steal). Generally, however, you aren�t doing amazingly sophisticated <br/>
things with scripting languages, so this is not too much of a hardship. <br/>
One scripting language that you can expect a Web browser to support without a plug-in is <br/>
JavaScript (this has only a passing resemblance to Java and you�ll have to climb an additional <br/>
learning curve to use it. It was named that way just to grab some of Java�s marketing <br/>
momentum). Unfortunately, most Web browsers originally implemented JavaScript in a <br/>
different way from the other Web browsers, and even from other versions of themselves. The <br/>
standardization of JavaScript in the form of ECMAScript has helped, but it has taken a long <br/>
time for the various browsers to catch up (and it didn�t help that Microsoft was pushing its <br/>
own agenda in the form of VBScript, which also had vague similarities to JavaScript). In <br/>
general, you must program in a kind of least-common-denominator form of JavaScript in <br/>
Introduction to Objects 35�<br/>
order to be able to run on all browsers. Dealing with errors and debugging JavaScript can <br/>
only be described as a mess. As proof of its difficulty, only recently has anyone created a truly <br/>
complex piece of JavaScript (Google, in GMail), and that required excessive dedication and <br/>
expertise. <br/>
This points out that the scripting languages used inside Web browsers are really intended to <br/>
solve specific types of problems, primarily the creation of richer and more interactive <br/>
graphical user interfaces (GUIs). However, a scripting language might solve 80 percent of the <br/>
problems encountered in client-side programming. Your problems might very well fit <br/>
completely within that 80 percent, and since scripting languages can allow easier and faster <br/>
development, you should probably consider a scripting language before looking at a more <br/>
involved solution such as Java programming. <br/>
Java <br/>
If a scripting language can solve 80 percent of the client-side programming problems, what <br/>
about the other 20 percent�the �really hard stuff�? Java is a popular solution for this. Not <br/>
only is it a powerful programming language built to be secure, cross-platform, and <br/>
international, but Java is being continually extended to provide language features and <br/>
libraries that elegantly handle problems that are difficult in traditional programming <br/>
languages, such as concurrency, database access, network programming, and distributed <br/>
computing. Java allows client-side programming via the applet and with Java Web Start. <br/>
An applet is a mini-program that will run only under a Web browser. The applet is <br/>
downloaded automatically as part of a Web page (just as, for example, a graphic is <br/>
automatically downloaded). When the applet is activated, it executes a program. This is part <br/>
of its beauty�it provides you with a way to automatically distribute the client software from <br/>
the server at the time the user needs the client software, and no sooner. The user gets the <br/>
latest version of the client software without fail and without difficult reinstallation. Because <br/>
of the way Java is designed, the programmer needs to create only a single program, and that <br/>
program automatically works with all computers that have browsers with built-in Java <br/>
interpreters. (This safely includes the vast majority of machines.) Since Java is a full-fledged <br/>
programming language, you can do as much work as possible on the client before and after <br/>
making requests of the server. For example, you won�t need to send a request form across the <br/>
Internet to discover that you�ve gotten a date or some other parameter wrong, and your client <br/>
computer can quickly do the work of plotting data instead of waiting for the server to make a <br/>
plot and ship a graphic image back to you. Not only do you get the immediate win of speed <br/>
and responsiveness, but the general network traffic and load on servers can be reduced, <br/>
preventing the entire Internet from slowing down. <br/>
Alternatives <br/>
To be honest, Java applets have not particularly lived up to their initial fanfare. When Java <br/>
first appeared, what everyone seemed most excited about was applets, because these would <br/>
finally allow serious client-side programmability, to increase responsiveness and decrease <br/>
bandwidth requirements for Internet-based applications. People envisioned vast <br/>
possibilities. <br/>
Indeed, you can find some very clever applets on the Web. But the overwhelming move to <br/>
applets never happened. The biggest problem was probably that the 10 MB download <br/>
necessary to install the Java Runtime Environment (JRE) was too scary for the average user. <br/>
The fact that Microsoft chose not to include the JRE with Internet Explorer may have sealed <br/>
its fate. In any event, Java applets didn�t happen on a large scale. <br/>
Nonetheless, applets and Java Web Start applications are still valuable in some situations. <br/>
Anytime you have control over user machines, for example within a corporation, it is <br/>
36 Venkata Pilaka Venkata Pilaka <br/>
Comments
Post a Comment