Site Search
Content Tools
Main Content
Why Java Applets have no Place on the Web
Introduction
It's no secret that the Write once, Run anywhere (WORA) methodology of Java is flawed in many ways, leaving many to believe that the slogan is a euphemism for Write once, debug everywhere. The same slogan is applicable to Java applets.
The problems, however, become more ubiquitous with applets as developers need to contend not only with multiple platforms, but also the idiosyncrasies of cross-browser support. Let's discuss some of the problems of Java applets in more detail.
Embedding Java Applets
At the time of writing, the current W3C standard for Markup is HTML 4.01 (XHTML 1.0), which specifies that objects should be embedded into web applications using the <object> tag. Although this is the standard, its by far the least supported way to embed objects, the most supported being to use the deprecated <applet> tag. In fact, using the applet tag is only way to get support for embedding objects with the most common browsers in use today.
As a developer, using deprecated functionality to achive cross browser compatibility is not only annoying, but also creates an uncertain future for the stability of the code - the next browser version could remove support for the deprecated feature.
Live Connect and Java
To achieve anything worthwhile beyond a simple Java applet, communication between the applet and the browser is required. Live Connect, developed by Netscape, was the solution to achieve communication between objects, including Java applets and flash objects, and other elements within the document. However, in reality, Live Connect suffers from the same innate problems as java applets - every browser has its own implementation. Although in theory you can develop your applications to make use of Live Connect generically and with cross-browser compatibility in mind, you will soon discover that to circumvent the flaws of each browser implementation, your once flawless theoretical design becomes nothing short of a hack.
Development Time
Designing and developing code in Java is far more tedious and time consuming compared to those programming languages that you would normally assiociate the rapid development, KISS and extreme programming paradigms with. If the Java applet is a non-trivial core part of the application, the development time of the applet could be a substantial amount of overall project development time. It's also difficult to combine methodologies that web developers generally adhere to, and those methodologies that Java generally benefits from, for example, API development.
Look And Feel Issues
Tring to incorporate the look and feel of your web application into a Java applet can be a daunting task. The look and feel of swing components is achived using low level graphics manipulation, contradicting the high level nature of web. It's not hard to see that swing components were designed for applications, and not with the web in mind. They where developed to appear like native applications on the platforms they where invoked on.
Limited Web Exposure
How often do you come across a Java Applet on the web? What incentive do browser developers have to support and further develop a feature that is rarely used? Many browsers, especially on Apple platforms, have been rather slow in supporting features like Live Connect. Until recently, most Mozilla based browsers on OS X only supported applets that were developed in Java 1.3 or earlier.
So what are the Alternatives?
For many people there will be no alternative as you would have adopted Java on the basis of strict requirements like interoperability with current Java applications or the underlining operating system.
If you adopted Java applets to overcome the stateless nature of the browser, emerging technologies like AJAX coupled with DHTML might be a more appropriate solution. The implementations of their underlining technologies, for instance javascript, are well supported, widely adopted and easy to learn.