By: Bruce Eckel
Abstract: The sources of client-side programming difficulties are many, but there may be more server-side solutions than you think. By Bruce Eckel.
The sources of client-side programming difficulties are many, but there
may be more server-side solutions than you think.
Client-side programming, if you haven't already figured this out, doesn't
work. I've tried to put client-side programs up on my site, both Java applets
people who think my site is broken. Do I want to explain to these folks
that "all" they have to do is download and install a new browser? No.
I take the easy path that most programmers have more or less quietly taken: I
remove the client-side stuff.
If those CERN folks who invented the Web had
anticipated that it would be used for anything other than viewing static documents, they might have been more careful. Big
apps like browsers take time and a certain level of expertise to download and
install -- and that translates to inertia. People don't want to change their browsers. Or in the case of the bazillion AOL users, can't
change browsers because they don't know how.
The folks who make the browsers seem to think that the world will jump at every new upgrade they post. They're programmers, after all, and assume that everyone has the basic skills to download and install a piece of software.
Out in the real world, you have to assume that there are lots of really old browsers, and that no one can view anything but plain HTML.
What "intranet" really means is that you can put the browser of your
choice on the client (along with plug-ins, Java, whatever) because within a
company the browser is usually standardized. But "Internet" means plain HTML. Yes, I know
First, the name: It used to be LiveScript and
making them think they know something about Java). Nor am I pleased with the
syntax; clearly, this language was invented by amateurs. Finally, the
implementation guarantees trouble if you try to do anything at all sophisticated.
You'll get it working on your browser, but ridiculous error messages will
It worked fine on my browser, but no one else's. To me, a language that creates applications which can't be reliably tested is ludicrous.
Applets seemed much more promising, especially when browser makers seemed to be getting on board with Java. But even when browsers
came along that would run Java 1, most of the installed base of browsers wouldn't, and some users were behind firewalls which wouldn't allow
applets at all. Then
came the Microsoft-Sun debacle (I'm applying blame equally here), and finally Sun has created the Java
plug-in. This would probably have been the best solution all along. Plug-in technology is pretty standard, and using a plug-in means you're not beholden to the browser maker (whose
browser will be spurned unless he supports plug-ins). Will everyone now
agree to have Java 2 (and Swing!) on their browsers? Of course not. The download is megabytes, and that's still going to scare people who worry about installing software (of course, installing a plug-in is a much fuzzier experience than installing a whole browser).
All applets would still have to be written using Java 1, and many browsers
out there still couldn't hack it.
Plain HTML isn't sophisticated enough to create dynamic Web pages. The real answer
is plain HTML generated by server-side programs. Of course, we've been doing this all along, typically using the everyman's hacking language,
If you're like me, you start out in stunned love with Perl; it does so much for you, so much more easily than your familiar systems languages like C++ or Java. This honeymoon can last
awhile, but eventually you discover Perl's references and objects. And the Perl credo, "there's always more than one way to do
it," becomes a curse with large complex
programs. This is especially true when reading someone else's code; you can spend
a lot of time, only to discover a piece of code is doing something you already know how to do, and that isn't
important in the grand scheme of the program. I may seem to be Perl-bashing, but
I still write most CGI scripts in Perl, and I consider it a very good scripting language.
Similarly, Visual Basic does the job as long as you don't try to go outside of its limitations
(usually a few pages of code). Then you begin hitting the wall. Productivity goes down, maintenance costs go up, and your chances of completing the project diminish.
Using Perl for small things is fine (also check out www.Rebol.com). But when programs get large and complicated, you need a language that's designed to scale up, like C++, Java, or Python.
Java is particularly well-suited to server-side programming not only because of its portability (both source and object code) and security, but because of its large set of standard libraries, and especially because of servlets. If you're building a large, complex server-side application, the combination of servlets and the standard Java library is very hard to beat.
In brief, a servlet engine lives on your web server and runs servlets (Java applications) in more or less the same way that a Web server now runs CGI programs. A servlet has access to the entire Java API (except GUI stuff, of course, since there's no UI for a servlet). But wait, there's more: once a servlet loads, it stays loaded, so the response time is very fast, typically faster than CGI programs. Only one instance of a servlet is loaded (unless you take special steps), and each client request becomes a thread within the servlet. This means that you get a kind of
persistence within the servlet because values are held between servlet invocations.
Each call to a servlet becomes a thread so your applications are automatically scalable: if they're running too slowly you can just add more processors,
and the threads will be distributed to the processors. For many reasons, servlets are hard to beat.
In the past, running servlets was painful; you had to configure a Web server to run them, which wasn't easy. However, Sun's
personal servlet server (available as part of the Servlet SDK)
simple to run, and it lives on your local machine so you don't need to worry about networking (this is terrific during classes). If you want to play with servlets, the SDK is your first stop.
Happily, the concept of the "application server" has been evolving to include servlets. An
app server encompasses a Web server but also has other facilities
built in. For example, if the Apache Web Server
includes a servlet engine that installs automatically -- something that Apache appears to be moving toward -- then it's more than just a Web server, it's an application server (usually an app server has more than just one additional feature, though). In fact, since Apache will call CGI programs, you could think of that as a form of application serving, however crude. The Netscape Application Server already includes servlets, and I expect to see them as common additions to most Web servers.
Server Response from: ETNASC01