Flex, Rich Internet Applications, and Cheminformatics

Rich Apodaca — Fri, 25 May 2007 11:32:00 +0000

Building Rich Internet Applications (RIAs) is no easy task. The technologies are all there, but twelve years after the release of Netscape Navigator, Web developers are still hacking around browser idiosyncrasies.

From JavaScript to HTML, to CSS, browser quirks are still a fact of life. Browsers tend to disagree the most on the more advanced features, but examples of less advanced features requiring cross-browser work-arounds continue to suck up large amounts of developer time.

Even Java applets get in on the act. The interface between applets and the browser is the most poorly-defined aspect of the technology. Particularly with respect to keyboard focus, persisting applet state, and even initial activation, it's "write once, test everywhere."

Recently, I saw a presentation by James Ward on a technology called Flex that's aimed squarely at solving the Rich Internet Application problem.

Flex is a platform for building software that runs on the Flash multimedia player. If you've developed Java applets, you already know a lot about how Flex works. Here are some of the key points James brought up:

Flex applications are written in ECMAScript (aka JavaScript) and run on the Flash 9 runtime. The language offers, among other features, variable typing. This stands in contrast to the non-typed form of JavaScript typically used in browsers.
Sometime in 2007, Flex will be open sourced. The developer kit is currently a free download.
A desktop-native runtime for Flex called Apollo is nearing release.
A variety of eye-popping examples of Flex in action are available. My favorites so far: FlexBook and Picnik.

Adobe is clearly trying to position Flash/Flex as the successor to Java applets. By ensuring that Flash works the same way in all browsers, has a rich API for interacting with the browser, and is available on all platforms, they just might succeed.

Adobe claims that Flash is the most widely-installed multimedia browser plug-in. According to a recent study, nearly 99% of browsers have some version of Flash installed (congratulations to Rajarshi Guha for almost immediately getting the Name that Graph). Adoption of Flash 9, the latest version and the one required to run Flex applications, is significantly lower. My guess is that these numbers will rise quickly given the availability of Flash 9 for Linux and the mere 1.5 MB download footprint.

If Flex has anything going against it, it's probably the small footprint of the Flash player. One of the first things you'll notice about many feature-rich Flex applications is how long they take to download relative to comparable Java applets. What the Flash runtime lacks, your application may well have to supply on deployment.

I'm unaware of a single use of Flex/Flash in cheminformatics. This is really quite surprising given the highly visual nature of cheminformatics and the refined graphics capabilities of the Flash player. Even with it's limitations, Flex may offer solutions to a variety of difficult problems in developing Rich Internet Applications for chemistry.

Look Ma, No Applets!

Rich Apodaca — Thu, 09 Nov 2006 14:28:00 +0000

The state of the art in structure editors for chemical Web services is Java applets. Although closed editors have long dominated this field, Open Source editors are a possibly viable option. Java applets are great from a developer's perspective. But applets are avoided by some end users and IT support for their underlying need to install a Java plug-in of some kind and long startup times.

Through David Bradly's sciencebase, I came across a non-Java solution to the structure editor problem. The software is called WebME. WebME looks and feels similar to Java Molecular Editor. It loads quickly and provides a clean, inviting user interface. It should work in any modern browser. Most interesting of all, WebME works without a browser plugin of any kind.

The magic behind WebME is AJAX, which has been summarized by Paul Graham as "Javascript now works". By asynchronously interacting with a Web server as user interface events occur, WebME is able to cram a lot of functionality into a relatively small deployment package. The user interface is written in a mixture of HTML and JavaScript, thus eliminating the need for Java.

Although WebME's use of AJAX is innovative, other non-Java solutions to the structure editor problem have also been implemented. For example, PubChem have developed an editor in JavaScript/HTML for use with their popular service.

Despite its advantages, the AJAX approach does involve some trade-offs. For example, WebME is not nearly as responsive as, say, JME. I would imagine that unusually high network latency could further erode WebME's responsiveness. Furthermore, the subtle visual cues that make JME a productive tool, such as highlighting the node or edge the cursor is about to edit, are non-existent. It's unclear if this is a limitation of this particular version of WebME I used or the underlying technology.

AJAX is a promising new technology that may well have a place in producing ergonomic user interfaces for chemistry Web services. On the other hand, it wasn't too long ago that JavaScript "didn't work", was loathed, or simply ignored altogether. It may well be that Java applets undergo a revival similar to that of JavaScript, perhaps triggered by built-in support for applets made possible through an open source Java implementation. Regardless of how Java applet technology evolves, WebME's approach is worth serious consideration.

Depth-First: Tag applets

Flex, Rich Internet Applications, and Cheminformatics

Look Ma, No Applets!