Are applets making a comeback?

Good old applets -- do they deserve a place in your RIA toolkit today?

1 2 3 4 5 6 7 Page 3
Page 3 of 7

Danny Coward: I think some developers have turned to Ajax because its deployment model was easy and because JavaScript, in some flavor or other, is in every browser. I think Flash is riding the wave of media rich applications and the Flash runtime is widely deployed. I think as [Sun] added features to Java SE, we were slow to realize that we were getting behind in being the best development model and runtime for rich client applications.

So I think our JRE got heavy, and became perceived as this big thing that was slower to start than it need be for consumers using the apps, and I think our development model for GUIs, while rich and highly capable, became better tuned for more traditional desktop applications in the enterprise.

Romain Guy: Many programmers have pointed out many, many reasons [for the demise of applets] over the years. While it is true that deployment issues and loading times didn't help applets, I doubt it was the real reason for their demise. The best asset that Flex and Silverlight have is simply a great designing tool. It is very easy for non-programmers to pick up such a tool and get started on something that looks and feels nice. Their programming model is also easy enough to allow non-developers to learn it and use it efficiently enough. Competing on the RIA market today is, to me, not viable without a good tooling solution.

Chet Haase: I think deployment continues to be the single-biggest issue with applets in the real world. Although Java now comes bundled with a large percentage of new machines, there are still some users without the runtime, or without the right version for a particular application, so they need to install Java. Given the size of Java, the installation or update process is not insignificant, and some users may choose not to go through that process.

This, then, feeds back to potential applet developers and makes them decide either to use alternate technologies without this deployment issue, or to use earlier Java APIs (that were available in version 1.1) that may serve a larger base of users that have some flavor of Java installed (even the Microsoft VM). If they go the route of using applets that target older versions of Java, then they don't get the benefit of years of progress on the Java APIs, and their users don't get the benefit from the code being easier/faster to write, enabling richer content, and so on.

Or they give up and choose other technologies entirely. So the applet market tends to be stale and historical, at least in the consumer space where deployment cannot be mandated and managed as it is inside company networks.

Cay Horstmann: #1. Java on the end-user machine. It's a mess.

a) Which version of Java?

b) Is it integrated with the browser, both for applets and Web Start?

c) Does it actually work? Is there a conflicting JVM (Microsoft on Windows, Classpath on Linux)? Are there bits and pieces of an earlier installation that cause mysterious interference? Is the browser linkage broken? There is a good chance that Java is not properly installed for a given end-user. Unless you enjoy doing tech support for them, that's a huge disincentive.

#2. Programming model. Java has no API for flashy transitions or rich media. If you want a consumer look, you can hire either very bright Java programmers or just code it in Flash.

Ted Neward: A couple of things combined to make applets unpopular: First, the difficulties of writing AWT (and later Swing) code by hand, compared to the drag-and-drop model of UI composition favored by other tools, though I think this wasn't so much a criticism of applets as GUIs-in-Java in general; second, the relatively limited functionality of the early AWT releases meant that Java developers could produce GUIs that were basic block-and-line diagrams compared to the sexier (though limited compared to today) three-dimensional effects that were appearing on the individual operating systems, most notably Windows 95; third and quite possibly most of all, for a variety of reasons, browser support for Java stalled, leaving only JDK 1.1 in place by default. This meant that not only would users of your applet-based systems be limited to UIs that were built on top of AWT 1.1 (unless you forced your applet users to sit through the sizable Swing .jar download), it also meant that many of JDK 1.2's notable enhancements were also lost to you, such as Java's new collection classes and thread enhancements. Java developers weren't ready to give that up, yet trying to make the Java Plug-In (once it came out) just struck many IT shops as too much work -- the point of a browser-based application is zero deployment cost, and having to push (or trick clients into pulling) the JDK onto the target machine seemed counterproductive.

These elements by themselves weren't enough to drive developers to Flex/Silverlight/Ajax -- those tools hadn't really been developed yet -- but it did drive developers to prefer HTML-based UIs over "richer" UIs, which were easier to control and deploy. That in turn led to the general realization a few years later that HTML's expressiveness as a UI is highly limiting, creating pressure to find something "snazzier" to dress up our applications in, and thus was born the drive to pick something -- such as DHTML, Flash, or even PDF. When Flex came, making it easier for Java developers to connect to Flash-based front-ends, that made for a compelling story. Silverlight has yet to really prove itself in the market, but already people are exploring how to connect Silverlight front-ends against Java back-ends, with some mixed results. (No doubt Microsoft will push that envelope harder as the interoperability story evolves.)

Jim Weaver: Deployment of the Java Virtual Machine (JVM) has been the biggest issue. Back in 1995 when the JVM was introduced, I thought that it would quickly become ubiquitous on operating systems and in browsers. Then the browser wars, etc., happened, and 12 years later we're finally getting to the point where the JVM will be nearly ubiquitous soon.

John Zukowski: My clients have typically been in the corporate world, not needing public deployment of solutions/applications. For that environment, they've usually had client-side, Swing-based applications, sometimes deployed by Webstart/JNLP off a corporate server to keep the latest version on the user's machine. They don't want something where you are tied to running within a browser. I have yet to run into anyone interested in using Silverlight. With at least Flex and Ajax, they work fine when Web-based solutions are needed. With things like Adobe AIR, that is more like the client-based, browser-disconnected approach I typically run across. For all of these worlds, applets are typically avoided for both perception and what I would call trend-following reasons.

Since the early days of the Java platform, applets were always thought to be not worth the hassle of creating. There were issues with dealing with browser differences, including from a security perspective, packaging differences (CAB vs. JAR), and just outright incompatibilities, runtime versions were not always the latest on user machines, and you couldn't assume the world had broadband to force them to get the latest. All of those issues have been addressed with newer releases of the Java runtime environment / Java Plug-in. Though, broadband everywhere can get a little questionable, depending upon your user base. Even startup time has been addressed, though sometimes you wonder if it is just faster hardware that doesn't just help perception quite a bit.

As far as the trend-following comment goes, it seems good developer talent is in more limited supply these days. With those that are available, it is easier to sell a solution using a technology that someone just finished using than to learn something new. With companies, this helps them retain the good developers they already have, as otherwise, they may learn the new technologies elsewhere.

Java SE 6u10: The client-side panacea?

Needless to say, none of the problems discussed so far are new to applets, and most of them are addressed in Sun's most prominent client-side initiative, Java SE 6 update 10. If the problem is applet execution -- with the symptoms being JRE deployment, startup performance, and JVM reliability -- then Java SE 6u10 offers the following solutions:

  • Java Deployment Toolkit: Simplifies the task of deploying applets and applications to a variety of clients. It consists of a JavaScript file (named deployJava.js) and a browser plug-in (currently for Windows only) that make it possible to automatically install a JRE.
  • Java Kernel: Lets first-time Java users run applets and applications faster by downloading only that part of the JRE needed to immediately run the applet/application, and subsequently downloading the rest of the JRE in the background.
  • New download engine and patching algorithm
    Beginning with Java SE 6 Update 11, a new download engine will work with 6u10's new patch-in-place strategy (future JRE updates will be applied in the existing JRE directory so that only changed files need to be downloaded) to reduce the size of future updates. To avoid interfering with a user's Internet usage, this engine will monitor that usage and throttle back its own bandwidth. Furthermore, the engine will automatically resume interrupted downloads.
  • Java Quick Starter: Pre-fetches portions of the JRE into a memory cache, greatly reducing the average Java platform cold startup time (the time to launch a Java applet or application for the first time following a computer reboot).
  • New Java Plug-in: Improves reliability by running applets in OS processes separate from the browser. If an applet fails, the browser is not affected. Other improvements include each applet being able to increase its heap size and improved Java/JavaScript communication.

On the face of it, these technologies should improve the user experience with applets, thus making them a viable alternative for Java-based rich client development. Responses from the applet think tank were more varied.

1 2 3 4 5 6 7 Page 3
Page 3 of 7