Greg Brown's Blog

Re-Inventing the Applet

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?

Comments

• I always thought (hoped?) that Flash/Flex would end up running on the Java platform.

  ColdFusion ended up being a J2EE app running on JRun (or others).
  Flex Builder 2 is an Eclipse plugin.
  ActionScript 3 is a very nice language, which in my mind, makes C# look clunky.

  Macromedia/Adobe built a new VM for Flash 9 that is very fast, but could they have used Java?

  I'm all for JBAs with a new declarative GUI framework, but Flex may well to succeed, even though it's now a bit slow and buggy.

  Posted by: goron on March 06, 2007 at 10:47 AM

• I have often thought of building a browser plugin for SWT that would use just the JavaME/CDC Java VM (which includes RMI support) and SWT. Such a plugin would come in at a little over 3MB.
  I think that such a plugin would be a better alternative than Flex for building web-distributable database applications
  I really don't understand why Sun doesn't create a Windows Java Plugin distribution based on the CDC VM. It would be a way to get a base version of Java widely distributed.
  

  Posted by: emorning on March 06, 2007 at 10:56 AM

• If the enemy is Flash, I think that F3 or something similar would be the way to happiness. BUT, making fancy animations with it should be as easy as in Flash FOR A DESIGNER GUY, that is, there must be good tools (design tools, not programming tools) to support them. Programmers, in general, are terrible (graphic) designers. The areas of the brain used are just completely different. let's do our own job, and let them do their job.

  I also think that this idea of creating a super-lightweight java distribution doesn't solve a real issue. People download files larger than the JRE to install Firefox, real player, quicktime, .Net, or whatever software they feel they need. The real problem is not the size of the download, but THE FEEL THEY NEED IT. If Flash was a 30 Mb package, I would still download and install it, because I want to watch funny videos, or play games, or be able to view some fancy sites. If these applications were implemented in Java, I doubt anyone (maybe besides java developers?) would complain about the size of the initial download.

  That said, the 10 seconds my browser freezes when I first enter an applet-enabled site really annoys me, the JRE installation/updating process could be simplified (well, maybe this one is already solved?), and 5.0 is still the default consumer version (WebStart windows are still so damn ugly and scary).

  Posted by: ronaldtm on March 06, 2007 at 10:59 AM

• RE: ronaldtm

  >If the enemy is Flash...

  I don't think any technology is the "enemy", but Flash, Flex, WPF, and AJAX certainly compete with applets for mindshare in the rich client developer community.

  >I also think that this idea of creating a super-lightweight java distribution doesn't solve a real issue.

  While working as a consultant, I pitched applets as a solution to a number of business problems. Universally, applets were rejected for the following reasons:

  
  1) Cross-browser/JVM compatibility (MS vs. Sun)
  2) Plugin download size/installer complexity
  3) Performance issues
  4) Limitations of AWT/complexity of Swing

  Issue #1 has been pretty well resolved at this point via the Java plugin. However, #2 - 4 are still valid, as far as I'm concerned. A slimmed down plugin that is as easy to install as the Flash player and is comparatively easy to develop for would go a long way to resolving them.

  >the 10 seconds my browser freezes when I first enter an applet-enabled site really annoys me
  >WebStart windows are still so damn ugly and scary

  Agreed.

  
  RE: goron

  >ColdFusion ended up being a J2EE app running on JRun (or others). Flex Builder 2 is an Eclipse plugin...Macromedia/Adobe built a new VM for Flash 9 that is very fast, but could they have used Java?

  Interesting points...

  >ActionScript 3 is a very nice language, which in my mind, makes C# look clunky.

  Eh...ActionScript isn't bad, but I don't think it's quite as useful as C#.

  >I really don't understand why Sun doesn't create a Windows Java Plugin distribution based on the CDC VM. It would be a way to get a base version of Java widely distributed.

  Agreed. That was actually the original premise when the idea first occurred to me a few years back.
  

  Posted by: gkbrown on March 06, 2007 at 11:57 AM

• I found Java Applet is very limited (I thing that applet have to be packaged in a single jar. but I could be wrong). Anyway, I would definitevly take a look at Webstart..

  Posted by: dreif34 on March 06, 2007 at 10:54 PM

• The JBA has been talked about for so long it is no longer relevant, download size of Java isn't all that bad. The main problem is deployment of Java, it sucks when compared to Flash. It requires admin privileges, when install fails you end up with a broken install that can't be repaired (unless you know how to edit the registry). Then there are the many open bugs about Applets/JWS related to everything from caching to other basics, slow startup time (that freezes the whole browser) and quite a few stability issues...
  I develop quite a bit on the client and Java deployment isn't making serious progress because the deployment team is "feature oriented" rather than working on stability and testing.

  Posted by: vprise on March 06, 2007 at 11:14 PM

• Many _developers_ would like to code in Java the GUI that runs in the browsers.

  I've been reading post like this one for years and nothing gets done. My guess is that nothing will happen.

  Today the main problems are:
  - complex installation
  - developer doesn't control the java version on client
  - and the load time (compared to Flash).

  Now I think that java is out and Apollo will deliver what most people are waiting.
  I don't think that what you are wishing will become a reality.

  Posted by: imjames on March 06, 2007 at 11:34 PM

• When talking about Rich Internet Applications, maybe we should also be thinking beyond a document-embeddable player ie. in the browser, to a windowing paradigm ie. leveraging the desktop window manager, task bar, system tray, et al.

  Posted by: evanx on March 07, 2007 at 02:34 AM

• but applications developed with Flex tend to seem slow

  Slower then AWT/Swing? Slower then Java 2D? Are you kidding?

  and the Flex platform itself seems (from my experience, anyways) fairly complex and a little buggy.

  From your _zero_ experience, I guess :))
  If you tried both Swing and Flex, then you are lying here. Otherwise you don't know what you are talking about

  Having worked with Flex for 8 months I have to say that Flex is _little_ bugy. Having worked with Swing for 3 years I may say that Flex is bugs-free :)) Unfortunately, Flex Builder IDE from Adobe is really a box of bugs, I hope that IntelliJ will provide a solid replacement with IDEA 7.0

  VS
  

  Posted by: vsilaev on March 07, 2007 at 03:21 AM

• It needs a high quality browser written in java. This way java technology like applets or java webstart would rule the web.

  Posted by: gruenewa on March 07, 2007 at 06:33 AM

• RE: vprise

  > The JBA has been talked about for so long it is no longer relevant, download size of Java isn't all that bad. The main problem is deployment of Java, it sucks when compared to Flash.

  I actually think it is more relevant now than before, specifically because comparable technologies like Flex, XAML, and AJAX are continuing to emerge and gain traction. Developers are finally looking to move beyond the limitations of server-generated UI, and I think that Java should be an option for them.

  I think that download size is important, but you may be right that ease of installation is the bigger issue.

  
  RE: evanx
  > When talking about Rich Internet Applications, maybe we should also be thinking beyond a document-embeddable player

  I used to think the same thing, and it may make sense in a longer-term view. But right now, users are comfortable with the concept of running apps in the browser, so I think that the applet model still makes sense.

  RE: vsilaev

  >> but applications developed with Flex tend to seem slow

  > Slower then AWT/Swing? Slower then Java 2D? Are you kidding?

  This comment helps validate the suggestion that Swing (along with AWT and possibly Java2D as well) needs to get the boot. So thanks. :-)

  > If you tried both Swing and Flex, then you are lying here. Otherwise you don't know what you are talking about

  I've developed with Swing for four years, Flex for two, and Flash for two years before that, and my perception (as well as that of the users of apps I've built with Flex) is that Flex apps seem slow.
  

  Posted by: gkbrown on March 07, 2007 at 07:18 AM

• Applets are a great way to deploy java via HTTP. I'm using it frequently and it works like a charm: proven, stable, good performance. You should see the thing hop along after it is cached the first time. And automatic detection when a new version of the applet is placed on the server!

  Plus, after installing the Java once (and thus installing the plugin) upgrading or installing required JVM versions for applets is semi-automatic.

  I agree that it would be preferable that the JVM itself would be split up into on-demand downloadable JARs. But on the other side: what is 30MB nowadays?

  There is no need for a specific GUI library. There may be a need for a new GUI library. Although I'm pretty Swing savvy (wrote my own components, layout, painters, etc), it still not straight forward to use.

  Posted by: tbee on March 07, 2007 at 07:41 AM

• >this toolkit would support a declarative, XML-based UI markup language, >allowing developers to quickly build and deploy highly functional and >visually engaging applications.

  The JDNC proyect used to have JDNC Markup, exactly what you are asking for...
  http://wiki.java.net/bin/view/Javadesktop/SwingLabsJdncFaq

  Posted by: jdavi on March 07, 2007 at 09:10 AM

• RE: jdavi

  >The JDNC proyect used to have JDNC Markup, exactly what you are asking for...
  http://wiki.java.net/bin/view/Javadesktop/SwingLabsJdncFaq

  ...except that it's a markup language for Swing, which I don't want. I want a new GUI toolkit that is better than Swing and also includes a markup language.
  

  Posted by: gkbrown on March 07, 2007 at 09:26 AM

• The problem are not the GUI toolkits. The problem is that whole desktops freeze until the fscking VM gets its act together, finally finishes loading, stops burning CPU cycles and graciously decides to start executing the first line of the applet's code, instead of taking care of itself and degrading the computer to an VIC 20.

  This is not what people want. The don't want to innocently go onto some web page and be punished with a cafe pause for doing so.

  Then Java integrations into browsers are still not stable and VM and browsers together like to crash fare more often then a browser without running a VM. Forget applets unless you have the whole environment under control and very patient users, or users who are corporate sheep and don't dare to protest.

  Posted by: ewin on March 07, 2007 at 02:01 PM

• Applets Are Dead, RIP
  Sorry to spoil your fun, but applets aren't going anywhere. Flex and Ajax have already beaten us. It's case closed, game over.
  So, why are we even trying to focus on applets? We should be focusing on what's making Java great right now... The DESKTOP. Java Desktop is where it's at; Swing/SWT, Webstart, etc.
  Stand-alone Rich Client APPLICATIONS are where it's at. Seriously, what killer Ajax/Flex/Applet web applications are out there besides email clients?
  There is a whole open landscape of opportunity out there for desktop applications, non browser based, networked web apps. Microsoft gets it, Sun gets it, IBM gets it, Oracle gets it. One of the big boys are going to create a killer stand-alone rich client web application, and the whole world is going to change from Browser based to Desktop based.
  It's not a matter of "if", but "when". And, more importantly, are you going to be ready?
  

  Posted by: bobsledbob on March 07, 2007 at 04:44 PM

• Anyone here use GWT? If you're looking for a reinvention of the applet, I'd say GWT is it. Write your AJAX app in Java, have it "compiled" to JavaScript, and start off with a pretty healthy dose of browser and platform compatibility. I've been using GWT for awhile now, and I've got nothing but praise for it. It can seem a bit confining at first, but life does indeed go on without all of the standard classes.

  But anyways, its definitely worth trying out.

  http://code.google.com/webtoolkit/

  Posted by: brianp on March 07, 2007 at 09:09 PM

• Question is where we use it i have no problem downloading a huge java applet and runtime for my online gaming or a secure bank/share operation but for a small funny button i cannot.

  Applet will remain where it is today it will be a good tool for software prototype in java and online games which needs some more efficiency and network interaction then Flash

  Regarding the RCP , Frame work which will have java like language and flash like designer's tool will step ahead of other i think APOLLO is all about that only

  Posted by: javaniraj on March 07, 2007 at 09:12 PM

• processing.org

  Posted by: ilazarte on March 07, 2007 at 11:14 PM

• I couldn't agree more. I submitted pretty much that same comment to Sun around the last turn of the century. I don't think they're getting it. My speculation is that there are too many engineers sitting at the controls at Sun who have trouble viewing the issue from the point of the uninterested web end user. For a web technology to be successful it has to be as close to invisible to the end user as possible. Users don't care about technology, they care about content. They don't have more than a few seconds of their time to spend on e.g. installation of the technology that supports that content. Otherwise they're off to a different web site. So, downloading dozends of VM Megabytes and going through a whole VM installation "application" before you can view the page containing an applet cannot be part of the equation. My guess is the threshold for the level of pain a web user is willing to accept for installing supporting technology is somewhere around 15 seconds delay plus one mouse click. You have to be able to download and install your technology under constraints like these for it to get accepted. After that process you need to be able to show some content. You can then, incrementally, download and install more technology in the background as needed, but the initial experience is pretty important.

  Posted by: loeli on March 08, 2007 at 01:46 AM

• Pop over to www.java.com and look at what technology they are using for the "rich" content on their front page.....

  Unfortunatley this says just about all that needs to be said about the current state of applets

  Posted by: klopperq on March 08, 2007 at 04:14 AM

• RE: bobsledbob

  > So, why are we even trying to focus on applets? We should be focusing on what's making Java great right now... The DESKTOP. Java Desktop is where it's at; Swing/SWT, Webstart, etc.

  SWT, maybe. But Swing and WebStart are non-starters. They've both been around for a long time and neither one has gotten any significant traction.

  > Stand-alone Rich Client APPLICATIONS are where it's at. Seriously, what killer Ajax/Flex/Applet web applications are out there besides email clients?

  It's not about writing the "killer app". It's about enabling better user experience (and better developer experience) across *all* apps.

  > One of the big boys are going to create a killer stand-alone rich client web application, and the whole world is going to change from Browser based to Desktop based.

  Actually, I think Apple has already done that with iTunes. However, as I said in an earlier reply, users are accustomed to the idea of loading applications by typing a URL in the web browser's address bar. The concept is a lot easier to grasp than WebStart or ClickOnce. I think that someday, we may be able to leave the browser behind and develop for this sort of model, but I'm not sure that it will happen anytime soon.

  RE: brianp

  > Anyone here use GWT? If you're looking for a reinvention of the applet, I'd say GWT is it.

  I think GWT is a very cool proof of concept. But I'm not looking for a Java to JavaScript translation utility. I want to develop *real* Java apps that can run in the browser.

  RE: klopperq

  > Pop over to www.java.com and look at what technology they are using for the "rich" content on their front page..... Unfortunatley this says just about all that needs to be said about the current state of applets

  That's exactly my point. Applets need a re-boot. They are not practical for web application development in their current state.

  Posted by: gkbrown on March 08, 2007 at 06:40 AM

• When it happens,
  make sure the dialogs work.

  Posted by: lafros on March 09, 2007 at 07:26 AM

• I've had good experience downloading and using Thinlet applications. I think it's a good approach, for obvious reasons doesn't get much press from Sun as it's a competitor to Swing. But it's lightweight and I've found the apps quite usable.

  I'm also excited about what might be possible with F3.

  I used to be excited about the idea of Java applets/JWS applications coming into their own, but now I'm too burnt out. I want more than just demos of cool UI candy and I want some useful applications. I also want something that doesn't make web browsing a painful experience, e.g. "stop the world" apps.

  Also, I think the "browser edition" is irrelevant for most cases. I always have the latest JVM installed and it's the startup time for the JVM, and the download time for all the classes, that's the killer.

  Glad you're pursuing the topic.

  Cheers
  Patrick

  Posted by: pdoubleya on March 10, 2007 at 03:10 AM

• i agree with early posts that the biggest problems with applets are not the size of the JRE download or Swing but:

  1) the delay while the JVM loads.
  2) total freezes of the browser when loading.
  3) browser/plugin stability problems.

  unfortunately, points 2 & 3 are probably more under the control of the browser developers than the JRE/JavaPlugin developers. in my experience, stability varies between browsers and an applet that will crash one will not crash another (write once, debug everywhere?). every time an applet is loading under Firefox 1.5 on GNU/Linux the entire application (not just the window or tab that contained the applet) freezes until the applet is fully loaded. neither Konqueror running on the same desktop, nor Safari on Mac OS X freeze in that way.

  in my experience, browser/plugin conflicts cause browser crashes/freezes far more often that javascript and sadly, Java applets cause the most, including on Safari on Mac OS X where the JRE comes pre-installed. i guess this because the browser developers who wrote the html renderer also wrote the javascript interpreter or were intimately involved in integrating it. browser developers would have little to no control over plugin code or the different versions of a plugin that may get installed in their browsers by end users ... and despite browser incompatibilities, javascript is more integrated with browsers than any plugin can be - which is an argument for AJAX over Flash or Java when developing "Rich Internet Applications" ...

  while i agree that Java applets have been a failure at producing "Rich Internet Applications", i actually think that Java applets have been extremely successful at adding interactive content to webpages where that content complements the information content of the pages. by that i mean applets that are truly small "applets" that run entirely within the browser without launching any external frames or dialogs - good examples of this can be found at:

  http://www.molecularexpressions.com/

  regarding Thinlet: when i first encountered Thinlet, i think the most commonly installed version of the JRE was 1.4 (1.3 on Mac OS X) and Swing's performance problems made Thinlet really interesting, possibly even a "next big thing" ... and a way to revive applets ... some nice apps like ThinFeeder have been produced but Thinlet now seems to have lost the momentum it had a few years ago ...

  regarding Swing: i think Swing is getting a lot better: SwingLabs, Matisse, F3, SwingWorker now standard, Desktop API and now with JSR-296 is finally getting a simple standard Swing Application Framework. Java5 and Java6 saw real performance improvements and i expect those to accelerate in Java7 and beyond now that Sun's Java is GPL ...

  these links might interest people looking for XML based approaches to GUIs ...

  Thinlet:

  http://thinlet.com/
  http://thinlet.sourceforge.net/
  http://thinlet.sourceforge.net/showcase.html
  http://wolfpaulus.com/theodore/
  http://thinfeeder.sourceforge.net/

  Swing:

  http://www.swixml.org/
  http://swixng.sourceforge.net/
  http://swingml.sourceforge.net/
  http://www.swixat.org/docs/

  General:

  http://xul.sourceforge.net/

  Posted by: simonreid on March 10, 2007 at 08:47 PM

• It has been a deployment issue with Java and it still is. I don’t know if Sun would have another 10 years to re-invent applet but after 10 years of Java, the deployment is still an issue. Java isn’t slow and Swing isn’t ugly any more. Applet loading is slow but I think that it is a deployment issue. If the desktop really matters, than Java needs to have better deployment strategy and better media frame work, which goes with the rich client as well. The last update for JMF on Sun’s Java web site was 2004. Who is in charge there? Does that JMF group still exist at Sun?

  Posted by: jdevp2 on March 12, 2007 at 08:58 AM

• I've developed with Swing for four years, Flex for two, and Flash for two years before that...

  Then I guess your experience is related to Flex 1.5 rather then Flex 2.0. Anyway, for me it sounds unrealistic that Flex application of same functionality (including jazzy visual effects) is slower then Swing one.

  Also I'm really surprised that you find Flex API complex. Really, is it more complex then "pure" Swing ("pure" means no tricks like F3;)? For me Flex looks far simpler both for application development and UI components development...

  VS

  Posted by: vsilaev on March 12, 2007 at 09:48 AM

This work is licensed under a Creative Commons License.