Web Programming 101 Part Two, Client Side Scripting
| In Part One, Selena looked at CGI server-side scripting. In this part, he looks at the pros and cons of various client-side scripting options. |
However, this is not to say that other technologies are not extremely useful. Several technologies have proven to be just as important as CGI for the average internet developer. These technologies focus on putting the demands of computation in the hands of the client instead of the server. Thus, things like processing simple requests, maintaining state, and GUI (Graphical Usr Interface) presentation are handled by the web surfer's own computer instead of being handled by some web server hosting a site.
Client-side programming is based on the idea that the computer which the client is using to browse the web has quite a bit of CPU power sitting there doing nothing. Meanwhile, web servers are being tasked to death handling hundreds of CGI requests above and beyond their regular duties. Thus, it makes sense to share some of that burden between the client and server by taking some of the processing load off the server and giving it to the client.
As it so happens, much of what CGI does, can be handled on the client's side. Typically, the only time the server needs to be involved is when the web application needs to send email or access datafiles. Things like maintaining state, filling out forms, error checking, or performing numeric calculation, on the other hand can be handled by the client's own computer. The web browser need not check back with a CGI script everytime the user wants to do something. A "script-enabled" HTML page can carry with it instructions on how to handle certain events.
In the following figure, client-side scripting has reduced server load by over 80% for every client accessing the CGI script. And of course, since most of the processing is handled locally, the application as a whole runs 5 times faster.
Obviously, this solves many of the problems posed by CGI. Client-side applications maintain security by keeping server processing to a minimum. They are not restricted by HTTP and the GUI can be as pretty and sleek as any traditional software package out there.
The two most popular languages for client-side scripting are JavaScript (Netscape Navigator) and VBScript (Microsoft's Internet Explorer). Both technologies allow web programmers to encode short program "snippets" into their HTML documents which can be executed by a web browser. JavaScript Made Easy provides several excellent examples of JavaScript in action and Reaz Hoque provides a very straight forward tutorial on JavaScript basics. On the other side of the coin, Microsoft provides a good list of samples for VBScript.
Actually, script-enabled HTML pages can be fairly dynamic and do indeed cut down on the work of the sever. Of course, in any real application, there will need to be a CGI script on the server to email results or access data, but much of the work, perhaps 75% of it, is done by the client. This can cut down server load by 80% on complex applications.
Unfortunately, script-enabled HTML pages have their problems too. The most obvious problem, of course, is that the web browser program must be able to interpret the language used for scripting. And since Netscape and Microsoft are too knuckleheaded to build upon common standards, we are left in the cold. JavaScript programs continually break when viewed using Internet Explorer and VBScripts do the same when viewed with Netscape.
Thus, client-side scripting has remained primarily useful only for limited, controlled intranets where webmasters can be sure that all users are using the same browser software to view web pages.
Further, both JavaScript and VBScript are only limited languages meant for quick jobs with little complexity. Ticker tape animations and sub totaling are one thing, but a true web application requires a bit more umph.
Platform Independent Client-Side
Applications with Java
That very umph comes with Java. Java was originally developed at Sun
Microsystems in 1991 to provide a platform-independent programming language
and operating system for consumer electronics (TV sets, toasters and VCRs).
In syntax and execution, Java is a lot like a simplified version of C++. ("simplified" should be read in the previous sentence as "an improved"). It is a highly robust, distributed, high performance, object-oriented, multi-threaded language with all of the usual features. As such, it builds upon years of C++ development, taking the good and dispensing with the bad.
As it so happened however, Java did not make it into the consumer electronics market. Instead it wound up in our web browsers.
Java seemed to be a perfect fit for the web. The language itself was extremely small (as it was built to go inside toasters and alarm clocks with tiny amounts of memory). Thus it could quickly be transferred over the web.
Further, Java was platform independent. That is, any computer with a java virtual machine can run a Java program. Programs can be written anywhere and be run anywhere. This is crucial because, as we saw in the case of the client-side scripting languages, if a language can not run on any machine, it cannot be used on the web which must service every machine, language, and environment imaginable.
Platform independency works because Java is an interpreted rather than a compiled language. Unlike C or C++ code, when java is compiled, it is not compiled into platform specific machine code, but into platform independent byte code. This byte code is distributed over the web and interpreted by a virtual machine (typically built right into a web browser these days) on whichever platform it is being run. Perhaps a picture would be useful...
Thus, as a programmer, you need only concern yourself with the generic Java programming language and compile your applications into bytecode on whatever system you are using. You can then be assured that your bytecode will be executed correctly whether your clients are using Macs, Pcs, Unix boxes or anything else.
Java, of course, demands books worth of explanation and description. So, of course, we will not delve too deeply into the language here. Instead, I recommend that you browse through the resources collected at Gamelan which is the be all and end all of Java resource sites. There you can sample several java programs yourself and see how amazing Java really is.
Did I say amazing? Well, Java is certainly a great addition to every web developers tool box, but as you might have expected, Java has as many drawbacks as any of the other tools we've discussed already.
Java Sucks
Though Java can create interfaces that go way beyond the capability
of HTML, CGI, and Javascript. And though the language is extremely powerful
and portable, Java still has serious restrictions.
Of particular concern are the security restrictions built into Java such as the fact that Java programs (Java applet specifically) cannot easily write files to the local harddrive or get data from servers other than the ones they came from. While this may make the public more confident about the language (an important thing and perhaps worth the limitations it causes), it makes java programs fairly useless for the average developer who absolutely needs such capabilities to create full featured applications.
Further, java programs with a lot of logic take longer to download. If you went to the Gamelan site linked above and tried to run some example java apps, you certainly found that you had to wait quite a bit for them to download.
Similarly, because the programs run on the client's machine, they do not have access to resources on the server. Thus, a java program cannot even query simple flat-file databases located remotely without a proxy (some other program working as a helper on the server).
Finally, Java is still a new language. As such, it is plagued by all the bugs, inconsistency and incompatibilities that any new language is faced with. Though java boasts platform independence, in reality, programs run differently from platform to platform...if they work at all. Further, though programs might be platform independent, they are not browser independent. Each browser, in fact each operating system, has its own buggy virtual machine which produces different output for the same program. Thus, when you distribute a java program, you can never be sure exactly how it will run, or if it will be run at all.
Though the restrictions of Java are being addressed slowly, the picture looks bleak in the short term (next couple of years) for the internet developer. Although, code signatures, and other security fixes are arriving, they will still cause complications for the average web developer with regards to centrally storing information and trusting it. Security will be a continuing thorn in our sides.
But even still, if all of the well publicized inconveniences of java were solved tomorrow, there would still be issues preventing the average web developer from writing all their web apps with java. For example, not everyone has a database to program against or can afford the cost of JDBC (java database connectivity) proxy servers. In fact, it is safe to say that "most" web developers do not have those tools to work with. Typically, internet service providers do not allow customers to run servers of any kind through their account, let alone complicated database servers. Thus, in order to perform database management functions essential to many applications, the average web developer will still need to work with flat files on the server hardware...and this means CGI.
There are also issues preventing the spoiled "intranet" developer from using Java as well. For example, the JDBC standard will not necessarily help in a corporate environment in which some sort of proxy to a real database server may still be needed that can communicate across a firewall with a web server. Not only will java be blocked by a firewall, but it cannot use standard encryption standards to provide secure, encrypted transactions.
In short, though Java is a profound addition to our toolbox, it is not the answer to all our woes.
Conclusion: Stocking your Toolbox
As any good technician knows, there is no such thing as a "best" tool.
The best tool is dependent on a whole host of factors from the type of
task at hand to the personality of the marketing director. The best tool
is a fantasy.
Instead, every web developer should have at her disposal a wide array of tools to solve problems. Sometimes a server-side solution will be appropriate, other times a client-side solution will be best. Your main goal as a web developer is to develop an intuition about when to use which.
That said, I would like to suggest one combination of tools which I see as becoming extremely important for all web developers. The combination is that of CGI and Java. Consider the following Problems and Solutions...
- Problem:
- The average "Internet" web developer has probably already picked up Perl/CGI programming. Most have not picked up Java with the exception of being able to code GUI interfaces using various visual tools such as Symantec's Visual Cafe or Microsoft J++.
- Solution:
- A Java to CGI interface leverages existing Perl/CGI knowledge so that the core program logic can be located on a server while merely having to code a thin (very small and easily downloaded) GUI Java client. In addition, a developer experienced in Perl will be able to whip out 80% of their program in a short period of time using a language like Perl while leaving a mere 20% (The GUI) left to Java (A hard language for most people).
- Problem:
- Internet developers who do work for sites on a virtual web server or an ISP typically cannot use Sybase, Oracle, or another commercial database to store data via JDBC. Frequently, the ONLY option that these developers or consultants have is to do flat-file processing using CGI/PERL which generally has precluded the use of Java.
- Solution:
- A Java to CGI interface will allow applets to be created that can use flat-file databases that an average small-business can afford (free).
- Problem:
- Developers who have already invested a lot of time creating CGI/PERL for their site do not want to rewrite all their applications in Java.
- Solution:
- A Java to CGI interface will allow existing applications to be leveraged by allowing a developer to create a Java applet on top of an existing CGI script with minor modifications to make the CGI output data conducive to interpretation by the Java applet..
