Moving from Applets to Ajax

Dietrich Kappe, Friday, November 3, 2006 @ 1:58 pm

Say you're a big company and you've invested heavily in Java Applets as your RIA solution. Java is healthy, developers are plentiful, and life is good, right? Well, no, not exactly. There are still many things to worry about. While Java is still going great guns on the server, it's future in the browser is much less certain. Sun will continue to make sure that Java runs on Vista and it's successors and is as easy to install as possible, but it's clear that Microsoft's unbundling of the JVM started a slow but inevitable decline in Java penetration on the browser. These days, Flash is a better bet if you want a non-Ajax RIA on the browser.

So, if you are said Big company, what are you to do? You have a significant investment in Java and in a code base that works. You do business all over the world and have worked out issues such as internationalization and security. Switching to a technology like Ajax, which seems to splay your business logic into the browser for everyone to see, and has a bewildering set of platform-version-OS combinations for you to support, must be a frightening prospect to a product manager. Also, are you going to have to retrain your developers to work in Javascript and Java? Adding languages and environments adds cognitive stress and makes your development slower and more error prone.

If you can convince yourself that Ajax has all the features and capabilities you need, you are still faced with a choice of Ajax framework. This is a hard choice, and there are no easy answers. It partly depends on your long term IT and business strategy, so making generalizations on which framework is appropriate is a little dangerous, but I'll give it a shot.

1. My first reaction would be to stand pat with Applets/Swing and go with a framework such as Wiser, a widget server that will let you write Swing code but deploy to Ajax, Applet or Application. These technologies, however, don't seem to be fully baked and the companies supporting them seem to be small -- not the sort of entities that can pass the big company technology selection process.
2. Next I'd consider Echo2, swing-like (though not Swing) and fairly mature. It has some tooling and keeps your business logic on the server side. Your Java developers will feel right at home working with it. There are some drawbacks, however. First, Echo2 needs the whole browser. It is an application framework, not an applet framework and makes assumptions about it's control of the browser. If you've developed applets as a way of plugging in RIA into a more traditional web site, this may be an obstacle you cannot overcome. Second, to develop custom components, you will still need Javascript developers -- better ones than you currently have, though fewer than with a . Third, debugging is a bit of an art as yet. Fourth, backed by a small company, again. Finally, you're moving much of your UI processing to the server, which will increase your server capacity requirement.
3. If you can expose your backend logic as XML-based services, Tibco GI may be a nice approach. It's slick, WYSIWYG, but again will require your developers to learn Javascript. Also, exposing your backend as a set of services may be biting off more than you can chew. No one says they have to use your GUI client to interact with your services, and letting customers write their own clients can have unforeseen consequences. Last, Tibco GI is designed for intranets and thus supports only relatively recent versions of IE and Firefox -- not acceptable if you need to work with the general public.
4. GWT would allow your developers to write and debug in Java. There's good tooling as well. For the transition from applets to Ajax, I like this one the best. The drawbacks are many, however. First, it's not an officially supported product and is still under active development. The developments are all interesting and inspiring, but you're shooting at a moving target right now. As such, the widgets that are available right now are relatively limited and borrow heavily from traditional Javascript libraries such as Scriptaculous. Still, your Java developers can write new custom components in Java, though they will need a working knowledge of Javascript and the DOM.

If you can afford to wait a bit, I'd suggest putting a little bit of money into exploring GWT and see what develops. Then in six months to a year, you and GWT may both be ready to take the plunge.

Technorati : ajax, applets, java

agile ajax

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment