For a term that was only coined early in 05 (Thanks Mr. Garrett—perhaps like Google, Yahoo!, and Microsoft, we had no idea how we were going to describe the new Web UI we started two years ago), Ajax clearly rates an A in terms of generating buzz. The fair question now is to what degree the reality can live up to the hype.
After looking at the Zimbra Ajax client, Paul Ambrose (one of the WebLogic founders and a good friend) said “There is a special place in heaven reserved for whoever had the patience to get all the Javascript programming right.” On the mark I think. Building rich UI in Ajax today is simply too hard. For the systems programming teams of the leading web properties (e.g., Google, Yahoo!) and platform software companies (e.g., Microsoft, IBM, and little Zimbra), it is in reach now. But if we in the industry want to see Ajax follow in the footsteps of other Web UI technologies (PHP, ASP, JSP, and so on), we still have a lot of work to do.
For market potential, it is easy to be very bullish on Ajax. Ajax uniquely combines
• Richly interactive UI (The “async” in Ajax refers to an event driven UI rather than the nature of the network communications);
• Richly interactive client/server communications (which can be synchronously or asynchronously programmed);
• The look and feel of the Web! (Don’t undervalue this one—users are comfortable with the Web. While they may want a richer experience, they are generally not looking for yet another new UI);
• Seamless integration with other Web content or services (a.k.a. mash-ups)
• The zero cost installation/administration of a Web client (nearly essential for applications/services for customers and business partners);
• The security model of the Web (which has been proven highly robust in practice, and avoids mucking about with VPNs); and last but not least,
• The investment protection associated with being a Web standard.
So the potential is there. Now, how can we make Ajax easier?
First, I believe, we need to settle on a handful of widget toolkits/frameworks that allow Ajax developers to work with the higher-level abstractions they know (buttons, menus, tree views, drag-and-drop, etc.). Such toolkits also provide insulation from the underlying browser that can simplify cross-browser testing/certification. I don’t see the industry converging on a single Ajax framework, but I also think everyone building their own is not get us to the promised land either. Instead, we need for two to four such frameworks to find critical mass—think SWT, Swing, and AWT from the Java days. Zimbra is, of course, offering one such toolkit (modeled after SWT albeit in Javascript). At this point, I think Microsoft Atlas is the only technology nearly assured of reaching critical mass. We in the open source community need to converge on a couple of winning alternatives. The good news is that at least some of our toolkits are arguably starting out ahead. (As an aside, I think it will be very hard for proprietary Ajax frameworks to challenge Atlas, but the open source community has the collective innovation and wherewithal to compete.)
Second, we need comprehensive tooling that supports these two or three emerging frameworks. Developers need help in authoring Ajax projects, step debugging their Ajax code, inspecting the DOM, and so on. Once again I see this as largely a competition between Microsoft Visual Studio and open source alternatives like Eclipse. (It is simply too hard for small vendors of proprietary UI programming platforms to challenge Microsoft. It takes a community.)
The combination of framework and tooling can mean more than an order of magnitude in productivity improvement—it can be the difference between success and failure. Our job is not to bring Java UI developers (for example) to Ajax, but to do a better job of bringing Ajax to them.
Provided we in the greater open source community do what we need to do to get to critical mass in both frameworks and tooling (and with new work being released shortly, we are closer than you may realize), then Ajax success will be fueled by a healthy competition between the Microsoft and open source camps to see who can offer the more compelling platform and developer productivity. All Ajax developers and users will come out ahead as a result of that competition.
All this does not make Ajax a panacea—see in particular Adam Bosworth’s typically insightful comments, but we can make it an easier, more general-purpose tool for the toolbox.
Comments are closed.