Online Book Reader

Home Category

Beyond Java - Bruce Tate [24]

By Root 691 0
It was a simple idea—embed the JVM into a browser, and let the user just download Java byte code that makes up an applet as one more message (MIME) type. The browser would just hand the applet to the JVM. Initially, many companies deployed their first few applets with great success. Later, applets fell out of favor. Over the course of my interviews for this book, I found broadly different views of why they failed:

Deployment was hard. Applet developers discovered that they had traded one problem—deploying operating system upgrades and client applications—for another—deploying the ever-changing browsers, and synchronizing virtual machines.

Programming was hard. Applet developers had a hard time understanding an alien programming model, and integrating the applets seamlessly with the web page. Applets done well were often magnificent, but not many applets were done well.

The Netscape JVM was buggy. Some said that the buggy Netscape JVM killed applets single-handedly. If Netscape had better supported the notion of a pluggable virtual machine, applets might have had a better chance at success.

For whatever reason, applets faded into the background. But Java is a surprisingly nimble beast, at times. In the halls of Netscape, server-side Java emerged. Servlets (a term originally coined by O'Reilly) made server-driven Internet applications available to application developers. Sun capitalized on this movement quickly with a standard, and an open source implementation of a servlet engine called Tomcat . Servlets solved many of the problems of CGI-based applications, and enterprise developers had a new way to deliver applications to a desktop. The vision of an application in a browser remained, but the view logic had moved from client to server.

The server would build dynamic content and serve it to the client. Ironically, this "new" model was little more than a glorified green screen that you might find on a mainframe terminal or emulator. It did have some important subtle advantages:

While green screens were stodgy and old, the Internet was cool and new. Users knew how to use them because they had the Internet at home. They liked to use the new systems as much as developers liked to build them.

Browsers lacked the raw productivity of keyboard-driven interfaces, but it was much easier to train users on them. The user interfaces provided several subtle enhancements, like navigating through links instead of typing menu choices.

The server-side development environments were much more productive than their mainframe counterparts. Development environments, often Windows clients, were much cheaper.

Java's client-side development stagnated. Swing has long been criticized for providing a poor user experience, but the real limitations lie in the learning curves and ultimately the productivity of developers that must grab it by the throat and shake to merely coax a minimal application out of it.

But Java's emphasis quickly moved wholly to the server side, where it remains today. Java Server Pages (JSP) continued the evolution, making it easier for traditional designers to play a role in the development of web applications. More modular designs, with JSP tag libraries, portal components (called portlets), and MVC frameworks, continued the evolution. None of Java's user interface technologies has succeeded on the same scale of web-based applications, driven from servlets.

Moving Forward


The vision of Internet applications is not yet complete. Google is now experimenting with Ajax , which seeks to provide a better experience to users with generated JavaScript and XML that communicates with the server. Applications like Google Maps show that it's possible to create richer applications with JavaScript and active communication between the client and server, but we desperately need a new user interface technology providing the advantages of easily deployed servlets and the richness of applets. JavaScript is broadly available, but it's a haphazard, problem-prone scripting language that's different on

Return Main Page Previous Page Next Page

®Online Book Reader