Who needs an enterprise AJAX solution?

Extensive support is but one differentiator between commercial and open source AJAX frameworks

One thing that the AJAX (Asynchronous JavaScript and XML) development community has aplenty is choice. Want a free, open source AJAX framework? We have (alphabetically) Dojo, Ext, Google Web Toolkit, jQuery, MooTools, OpenRico, Prototype, Scriptaculous, and the Yahoo User Interface Library, and frankly they're all pretty good. There are hundreds more, but unfortunately I can't keep up with them all.

Want an enterprise AJAX solution and don't mind paying for it? We have Backbase, Bindows, Icefaces, Isomorphic SmartClient, JackBe, Nexaweb, and probably many more that I don't know about or didn't think to include. Want to hedge your bets? Almost all of these vendors offer a stripped-down community edition or a free open source license as an alternative to a fully supported offering with enterprise-level features.

[ Survey the many options for bringing bling to browsers. See the Test Center's guide to rich Web app dev tools and comparative review of open source AJAX toolkits. ]

The question is, with so many terrific open source AJAX tools, why spend good money for a so-called enterprise solution? I had some preconceived notions about what the answers would be, but I decided to go out and ask other people about it, both vendors and developers. I'll tell you what they said, and what I think now that I've talked to them.

Defining enterprise
One vendor executive, Ran Meriaz, president of MB Technologies, which makes Bindows, came back with a flowchart for selection. It boils down to two basic choices: First, do you want pure AJAX? If not, then look at other RIA (rich Internet application) technologies (such as Adobe Flex, Adobe AIR, Curl, and Microsoft Silverlight), since you can get additional capabilities and higher performance if you're willing to use plug-ins.

Second, are you building an enterprise application? If so, then look for a robust, enterprise-strength, object-oriented framework. If not, seek a solution based on JavaScript with individual AJAX components or small, lightweight AJAX libraries.

Now, the crux of his decision tree is the definition of "enterprise." Meriaz supplied some characteristics of an enterprise-strength framework. As you might expect, he specified a complete, extendable components library. I agree: If you're going to pay for an enterprise AJAX solution, it should do every common thing you need out of the box, and it should allow you to meet any special requirements of your own without going outside the framework. Open source solutions tend to focus on one area or another, at the whim of the developers.

Meriaz also asked for handicapped accessibility, in the form of adherence to Section 508. This is a worthy goal, although I'm not convinced that it's an absolute requirement for all enterprise applications.

He specified vector graphics, charting, animations, and layers. Those certainly can jazz up a site, but I wonder: How many sites really need all that? I'd consider this optional, but a big bonus.

Meriaz asked for internationalization and localization. That's a must only for sites that aren't limited to a single language and country.

[ Read the Test Center's reviews and screencast demos of Dojo, Ext, Google Web Toolkit, jQuery, MooTools, Prototype and Scriptaculous, and Yahoo User Interface Library. ]

Security? I agree absolutely, but I think that it's so important that you should require it of every software component you use and every piece of code you write. Not every open source library has undergone a full security review, although some have. The enterprise-class products usually have, since the vendors expect customers to care about security.

Meriaz mentioned pace of development, meaning documentation, tools, and support. These are often, but not always, clear differentiators between open source projects and commercial solutions. I demand support from a commercial product, and I'm willing to pay for it because of the development time saved, and because providing it costs the vendor real money. I expect commercial documentation to be complete, up-to-date, and well-organized, although I'm often disappointed; I expect open source documentation to be cursory and an afterthought, although I'm sometimes pleasantly surprised. Tools that truly speed up development are worth paying for, although they're often available gratis.

Before I started researching this article, I had a preconceived notion that one of the distinguishing features of enterprise AJAX would be support for various servers in addition to the client libraries. Several of the enterprise AJAX packages do have extra support for specific server frameworks: For example, Backbase has additional support for JSF, Spring, JSP/Struts, and Java Data Services. On further thought, however, this isn't necessarily the case: Once you have a robust asynchronous callback mechanism, a flexible data format (such as XML or JSON), and support for the data format on both the client and server, you don't absolutely require special support for any given server built into the client.

Behind the browser
Another industry executive, Isomorphic founder and CTO Charles Kendrick, told me two reasons why his customers adopt his product rather than FOSS AJAX: the desire for an integrated solution, and the desire to be insulated from browser idiosyncrasies. The integrated solution argument is basically Meriaz's complete, extendable components library. Kendrick's additional point about this is that allowing developers to cobble together different solutions can be a minefield without serious (and expensive) integration testing.

His emphasis on using the framework to insulate the developer from cross-browser issues is a big one. Kendrick said, "I personally think eliminating this problem is the No. 1 thing that an enterprise AJAX platform should deliver."

I myself have found that many AJAX frameworks, including the major free open source projects, do a pretty good job of smoothing out the differences between the JavaScript implementations in different browsers. Kendrick points out that some of the lighter-weight libraries (he mentions jQuery in particular) force you to deal directly with HTML, CSS, and the DOM.

I'm not convinced that dealing directly with the DOM is necessarily bad: Developers can do this independent of the browser, but I admit that it takes some skill and care. I don't mind doing this, just as I don't mind writing raw JavaScript, but not all developers and development managers will agree.

Developer perspectives
I talked to two developers. One had contributed to a case study that vendor Backbase did about its customer Serena, which wanted to replace a homegrown AJAX framework in its Business Mashups product; the company eventually chose Backbase. Why Backbase, and not any of the other AJAX frameworks evaluated, which included Dojo, TIBCO General Interface, and the Microsoft AJAX Library?

"Backbase Enterprise AJAX was a good fit for us for four reasons," said Pavel Kramer, a senior software developer working on this product. "First, it uses declarative XML; second, Backbase provides enterprise-class support; third, the framework has good performance; and fourth, it's easy to bind Backbase XML controllers to databases."

The other developer I talked with, Mike Willson, works for a large ISV that did not wish to be publicly identified for this article. He has been using Isomorphic SmartClient for two years, for an online time-sheet application that uses grid controls and lots of server-side Java components. He previously did his AJAX development with Dojo.

"Our biggest issue was support from the vendor. It was hard to get going in Dojo unless you happened to find an example of what you wanted to do. With SmartClient, the documentation is pretty good, but even more importantly the vendor is great about supporting the whole stack, not just their piece of it, and good about helping us with edge cases and extensions for our particular application."

I think the situation with Dojo support has improved since two years ago so that Willson's experience might not be completely applicable today. Jep Castelein, senior product marketing manager at Backbase, also suggested to me that "the availability of a skilled consulting force in case additional help is needed" is one of the marks of an enterprise AJAX solution.

While the Dojo documentation still has a few holes, it has been beefed up tremendously; in addition, there are at least two good books in print on Dojo development. It's also possible to find consultants who know Dojo well. Similar things could be said about jQuery, Prototype, Scriptaculous, and Ext. So on this particular point, I would draw the line between the lesser-supported open source libraries and the better-supported libraries, rather than between the open source AJAX libraries and the enterprise AJAX frameworks.

Willson, unlike Kramer, is a fan of JavaScript APIs and finds XML markup bloated. Kramer, on the other hand, found that declarative XML helped to make his application more robust, and that he was less likely to run into browser compatibility issues with XML than with JavaScript. Most enterprise AJAX products offer both kinds of API, and so do some open source AJAX projects. For example, Nexaweb did its own extension of Dojo to add XML markup, called DojoE; in June of this year, it contributed the source back to the Dojo project.

So I find that I have to give a consultant's answer to "Why buy an enterprise AJAX solution?" It depends on a number of factors. The biggest question by far, however, is whether you'll need extensive support. If so, you probably should pay for an enterprise AJAX solution. If not, then you may well be able to find a free AJAX framework that meets most or all of your needs: Just make sure that you have a strategy for dealing with future growth of your Web 2.0 project.

Copyright © 2008 IDG Communications, Inc.

How to choose a low-code development platform