The freedom starts to fade as you add enough of your own logic for gluing together the widgets, validating the inputs, or doing any other housekeeping. The JVM wants to speak Java and the AJAX layer wants JavaScript. There's no automatic way to push a button and make your application move from the Java client to the browser or back again, but the APIs are very similar. If you're writing code, the design patterns and structures are pretty equivalent. It makes me wonder if Nexaweb could incorporate a Java-to-JavaScript translator like the one used in Google Web Toolkit.

Click for larger view.

There are subtler differences that can be important. The Java version can offer a pure push option to the server because the Java code on the client can open a continuous connection. The AJAX code can only poll the server every so often. This may be an important distinction in some applications demanding heavy connectivity, such as apps for trading desks and other fast-paced realms. JackBe's JavaScript, by the way, can come close to approximating this by tricking the HTTP connection by sending down a bit of data every so often. It's not the same thing, but it can be just as effective.

A Java client is also useful in other ways. The Java APIs are rich with code for doing simple things such as loading local files and arcane things such as parsing image files. The Nexaweb Java client leaves these options open to you -- if you have client computers that are happy to open themselves up to the software. You can just link them into your code.

Click for larger view.

I tested the Nexaweb toolkit (Nexaweb Platform 4.5 and Nexaweb Studio 3.5) by building another tool that would mash up RSS feeds and display them in a browser. Nexaweb's back end offers many of the same features as Presto in different packaging. You can grab information from Web services, Web sites, and databases and then send them back over the "Internet Messaging Bus" to the client. The server can poll most of the same basic sources as Presto, but it can't manipulate the information as readily. Nexaweb's server doesn't have the same support for quick manipulation. You could certainly whip up most of this on your own, but it isn't as simple.

Drag and drop, you say
One of my pet peeves is that the marketing forces for both of these packages tend to suggest that building an application with Nexaweb or Presto Studio can be done without requiring any code to be written. Ha. Just because both applications include neat drag-and-drop tools that construct XML to describe the widget layout doesn't mean that you don't need to think abstractly and try to guess what the API wants to do. In both cases, I admit I was charmed by the quick ways to drag an RSS data source onto a table to produce a nice feed reader; I was also driven to tears by nasty little glitches that were the visual equivalents of sign errors. These are sophisticated systems that make life far easier, but you still have to think like a programmer.

The biggest competitor for both of these applications may be services like Yahoo Pipes, Google Gadgets, Metaplace, and any of the other mashup tools for the worlds of Facebook or Salesforce.com. These tools can similarly pull data from a number of sources, mix it up, and then deliver it to Web pages. They're simple and often free, or close to free.

Most IT professionals may be scared of such freedom, and with good reason. If the Nexaweb or Presto server does the mashing, it can decide on the rules for sharing information with the world. Control remains behind the firewall, not with some distant server farm owned by someone else. The downside of this tightfisted approach is that your customers will never surprise you with cool new applications or mashups, something that can be exciting until the so-called customers discover a way to embarrass or rob you. The obvious solution is to open up as many databases as practical but use tools such as JackBe Presto or Nexaweb to do the heavy lifting for more proprietary things.

The biggest customers for these products will be IT professionals with a deadline and a need to integrate a number of internal data sources. If the boss says that the customers need a single place to pull data and reports that tap disparate systems from different parts of the organization, then these are both good tools for creating a rich and usable application that hides some of the confusion going on in the background. They are even more valuable if the hidden sources can't be changed because the developer is long gone, too busy, or uncooperative. Scraping information from the other sources and integrating it all into one front end is quite useful. Both Nexaweb and JackBe Presto are ideal tools for the folks responsible for moving an enterprise's Web presence into Web 2.0 and beyond.