Applets: back from the grave?Applets: back from the grave?

Just when you thought it was safe to click…

The Wicket world is abuzz with an idea that gives many people the shivers—the return of the Duke.

No one has particularly fond memories of Java’s first incarnation as a client-side Web page enhancer. Remember how Netscape 3 would buckle under the strain of an unexpected (and unhelpful) dancing Java applet? The Duke was eventually abandoned by the Java brand, perhaps for his reputation of crashing browsers or because, well, he looks retarded.

The clown car of Java applets running on insufficient hardware didn’t take us to programming nirvana, but it did buy time for Java to find alternate niches. The technology has since made itself useful in cell phones (a platform-agnosticizing trick much closer to its inventors’ hopes than applets ever were) and unexpectedly dominated the compiled Web application scene.

Having relegated dancing Dukes and throbbing N’s to the annals of Web 1.0, the latest brainstorm from the creator of Wicket is a little jarring: integrating server-side Wicket applications with client-side applets. These applets, dubbed “sprockets,” share model data with the Wicket environment that bore them.

Script devotees must already be rolling their eyes; of course Java programmers would make another quixotic attempt at saving the Web with slow, awkward, Java-y interfaces. The past year of advances in AJAX has largely eliminated the need for anything like applets. Good AJAX apps do more than plain Web pages, and they just work. Case closed.

Well not really. I haven’t yet thought of anything super-great I would do with a sprocket that couldn’t be done in AJAX, but this is about possibilities. Applets can do loads more than any browser script. JavaScript, even with the very un-standard canvas, is not in the same category.

Wicket competes with frameworks written in newer and thriftier languages, but it uses Java’s heft to your advantage. Its primary strength is object oriented markup generation. In future versions, sprockets will allow you to draw arbitrarily to the user’s screen, collect mouse events, or even (please don’t do this) play audio.

In the war of Web programming frameworks, this is the atomic bomb. It’s a weapon of unknown power that the other guys have no hope of developing for themselves. Ruby? Yeah they wish they had an interpreter running in my browser right now.

Speaking of that interpreter, there is one applet I do use fairly regularly, a generator for pronounceable passwords. It runs fine on Mac Safari, Ubuntu Firefox, and (I assume) Windows IE.

It’s 2006, and Java applets no longer signal a mandatory coffee break. I smell a comeback!

Codercomments

While I haven’t tried it, changes to IE (due to a patent suit) will likely make applets a thing of the past (as well as ActiveX controls) - at least for the uses envisioned by sprockets.

Applet, Embed, and Object tags will now have to be “activated” by selecting them and then pressing space or enter.

This will make a bunch of activeX/java applets laid out in a page very cumbersome at best.

See the following for details: http://bink.nu/Article6301.bink

Users of Microsoft’s JVM won’t be affected, only people running Sun’s JVM on IE will have to “activate” applets.

You can already get a “script”:http://blog.deconcept.com/flashobject/ to work around the problem for Flash. The same should be possible for Java. And if Sun needs to change their JVM, I’m sure they will–long before we get our hands on any Sprockets.

Add a comment