Skip to main content

Re-Inventing the Applet

Posted by gkbrown on March 6, 2007 at 9:03 AM PST

For all of the (arguably justifiable) buzz AJAX is getting these days, it can still be a pretty painful technology to use for developing web applications. JavaScript, the programming language used to build AJAX applications, is interpreted and only minimally object-oriented. HTML, the UI framework behind AJAX, remains, at its core, a page layout language, not a GUI toolkit. AJAX is certainly a step towards building better web apps, but it is by no means the final step.

It's time for the applet to make a comeback.

Applets were the original "rich client"-enabling technology. However, due to some early performance and compatibility issues, as well as the "lowest common denominator" approach taken by the AWT, they never really took off. Now, after over a decade of increasingly complex server-generated UI, new applet-like technologies are beginning to emerge:

  • Microsoft's XAML Browser Applications, or XBAPs, are mini-applications that can be embedded in web pages. They are based on the Windows Presentation Foundation (WPF), a new, Windows-only, UI technology that is a key component of .NET 3.0 and Windows Vista. A lighter-weight version called WPF/E (for "WPF/Everywhere") is cross-platform and is tentatively scheduled for release later this year.
  • Adobe's Flex uses a combination of MXML, a UI markup language created by Macromedia, and ActionScript, an ECMAScript variant similar to JavaScript, to deliver rich client functionality via the cross-platform Flash player.

So, while applets may have failed to gain widespread acceptance 10 years ago, there is clearly a continued, or at least renewed, interest in developing applications that can go beyond the capabilities of HTML. However, even these newer technologies have some limitations: XBAPs only run on Windows XP, Server 2003, and Vista, and require the .NET 3.0 runtime, which must be downloaded and currently weighs in at 50MB (though it may be pre-installed with Windows Vista). WPF/E is still in very early development, and, even when complete, will offer only a restricted subset of the the functionality provided by the full version of WPF; it includes only the most basic user input controls, making it unsuitable for developing all but the most trivial applications. Flex is more capable, but applications developed with Flex tend to seem slow, and the Flex platform itself seems (from my experience, anyways) fairly complex and a little buggy.

I think that it is time to re-introduce, and re-think, the applet.

Java is a solid, proven technology that is actively supported across all major operating systems and browser versions. What is needed is a streamlined "Java Player" that can be easily downloaded and installed by end users and is capable of running the "next generation" of Java-based web clients (I'll call them "Java Browser Applications", or JBAs, for now).

JBAs would run in a "lighter-weight" version of the Java Plugin, which, when first installed, would include only a minimal set of classes required by all applications. For example, the initial download might contain only java.lang, java.net, and possibly a GUI library (see below). Packages that aren't useful to most browser-based applications, such as RMI, JDBC, and CORBA, would not be included. However, the player would allow developers to specify additional required libraries to be downloaded (and cached) at runtime on a per-application basis, similar to Java Web Start. This would keep the initial plugin download size small but would allow developers to add additional functionality incrementally as needed.

Ideally, the player would include a new GUI toolkit optimized for delivering the best possible user experience on modern operating systems and graphics hardware (yes, it is time to deprecate the beleaguered Swing and AWT). Similar to WPF and Flex, this toolkit would support a declarative, XML-based UI markup language, allowing developers to quickly build and deploy highly functional and visually engaging applications. However, since such a toolkit does not yet exist, it might be useful to allow developers to specify a GUI package as a runtime download; this would allow the player to run existing applications built using AWT, Swing, or SWT without requiring built-in support for each toolkit, which would increase download size. The new, updated GUI library could be added in a later release of the player.

Though this represents something of a departure from the way Java is used on the client today, I believe it is consistent with the original vision of the applet and would create a strong platform for future web-based application development. Microsoft has created a very compelling technology in WPF; if they chose to make XBAPs cross-platform or WPF/E more powerful, the web development landscape would change almost overnight. But they won't, because a powerful, cross-platform application development technology will not help drive users to the Windows platform. Adobe does not seem to have enough mind share in the developer community to inspire developers to invest in the Flex platform, and, while AJAX is hot right now, the lack of a strongly-typed and truly object-oriented development language combined with the limitations of HTML will ultimately result in developers looking elsewhere.

Java on the client needs some new buzz, and developers need a new technology that can really move web development forward. Sun, what do you think? Are you ready to re-invent the applet?

Related Topics >>