JavaScript for Cheminformatics: An Introduction to WebSpex, a Spectroscopy Tool for the Internet 6
The previous article in this series discussed the untapped potential of JavaScript for building rich, chemistry-oriented Web applications. This article will describe the design of WebSpex, a spectrum viewer designed for the Web and written entirely in JavaScript.
Warning: Potential Vaporware Ahead
WebSpex can't yet be download or deployed, and it may never be finished. Articles like this one will document the tool's transition from concept to hopefully something more substantial. There may be false-starts and dead-ends along the way. But I'm hoping that there will also be feedback from readers like you. Feel free to chime in, regardless of your background.
This process will be necessarily non-linear. But I believe that being able to incorporate feedback in real-time increases the chances of creating a better product, and seeing mistakes, false-starts, and dead-ends in context can be useful to everyone.
The Problem
Of all the forms of chemical data generated in labs around the world today, spectra are one of the most common. Although several tools can display and manipulate these data, few are capable of being used on the Web. If you agree with the hypothesis that the Web is fast becoming the only information exchange platform that matters, this presents a significant problem (or opportunity, depending on your perspective).
Recently, a series of articles on the Web-based spectroscopy tool JSpecView appeared here. JSpecView is one of the only free tools currently available that enables spectra to be displayed and manipulated on the Web.
JSpecView is written in Java and deployed as an applet. In very many situations, applets are the best technology for delivering interactive Web content of the kind required by spectroscopy.
But no technology is perfect. One of the biggest limitations of applets is that they require the correct version of the Java plug-in to be installed on a users' machine (a limitation shared by all plug-in technologies, including Flash). In situations where users either can't or won't install the plugin, or in which adequate resources are not available to ensure smooth applet deployment, Java applets may not be the best technology platform.
What if there were a spectroscopy tool that worked on any browser without any plugin dependencies?
Scenarios
For a better idea of what WebSpex will be about, consider some scenarios:
Viewing Sally logs into her research group's spectroscopy archive website. She clicks on the link to her most recently-collected IR spectrum and is taken to a page displaying an image of her spectrum along with textual metadata.
Zooming Fred is viewing an IR spectrum published on a chemical supplier's Website. Wanting a better view of the fingerprint region, he uses the mouse to zoom the spectrum.
Peak Picking Victor is using a publisher website to view the IR spectrum of a compound described in a recent paper. Wanting to match the carbonyl stretching frequency of the material he prepared, he uses the mouse to pick the peak.
Data
WebSpex will use as its input format JCAMP-DX, the de facto standard for spectral data encoding. Although JCAMP-DX has been extended in many ways over the last several years, for now the goal of WebSpex will be to simply read and display error-free examples of the original format specification.
Conclusions
Good Web-based spectroscopy tools are a prerequisite for the open sharing of this important form of experimental data. WebSpex could fill this need by providing an installation-free tool that can be used in any browser without plugins. Currently consisting of nothing more than just some ideas, WebSpex successes and failures will be documented here in several installments.
Image Credit: estaticist


What's wrong with developing this as a Flash plugin? You've pointed out problems with the Java startup time, and the diverse implementations, but those don't apply to Flash.
The numbers I've seen are that 96% of personal computers has Flash installed. Of those who want to view spectra, that percentage is almost certainly higher.
Some people don't have Flash installed (iPhone users - I'm talking about you.) But some don't have Javascript installed. I can also see how to implement your scenarios using image maps and code on the server, which is the most portable, even to 10+ years ago.
Andrew, using Flash, most likely through Flex, is one of several options, each with its tradeoffs.
My main concern with using Flex/Flash would be the deployment footprint of the resulting software. The downside of the minimal Flash runtime is that more code needs to either be written from scratch or brought in from libraries not bundled with the runtime, which has been my experience so far with Flex.
(This could also be an issue with pure client-side JavaScript, but the lack of a plugin dependency could make a worthwhile tradeoff).
This isn't a reason not to try implementing a spectrum viewer in Flex (I think it would be a useful exercise); it's just a reason I'm keeping an open mind about alternatives.
I've seen the talk about Flex, and like it in part because of the Python support in Flex.
I don't think for this task that Flex is needed. Regular Flash is quite capable, so I don't think there's a deployment footprint issue.
We've all seen non-trivial Flash programs - mostly games. For example, here's an essay on using Flash as a game development platform http://www.drizzle.com/~scottb/gdc/flash-paper.htm .
As an example of what can be done in Flash without Flex, take a look at some of the OpenLaszlo demos at http://www.openlaszlo.org/node/409 .
Andrew, all good points. Another advantage of Flash is Flex Builder, which is apparently one of the better IDEs. It can be used for developing lightweight ActionScript apps of the kind you suggest with support for things such as profiling and refactoring.
A pure client-side JavaScript approach would no doubt be pushing the technology closer to its limits. If the comparison is with an ActionScript Flash program, then the only advantage comes down to lack of plugin dependency.
Have you seen Processing.js? http://ejohn.org/blog/processingjs-aftermath/
Noel, I hadn't seen it. Seems to be a port of a Java library for which some interesting visualizations written as applets are available (example).