The failure of client-side Java

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 and (shudder) JavaScript. In response, I get a flood of e-mail complaints from 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.

A few axes to grind

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 that some subset of JavaScript will probably work on most browsers, but who needs the headaches? That's not a solution.

Admittedly, I have a few axes to grind with JavaScript.

First, the name: It used to be LiveScript and was changed to make people think they were getting Java (it only deludes JavaScript programmers, 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 pop up on the screens of half your users. I once spent a couple of days learning JavaScript and creating a self-checking form (which doesn't seem that sophisticated to me). 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.

What is the solution?

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, Perl. 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) is 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.