Web 2.0 Design: The Ajax Spectrum
posted Wednesday, 8 February 2006
Yesterday I had the pleasure of talking with key people from two Ajax providers, TIBCO General Interface's Kevin Hakman and Zapatec Ajax Suite's Dror Matalan. Each company has two quite different approaches to designing Ajax-enabled software and it highlighted an increasingly clear divide in the way that people are thinking about online software. In these early days of Web 2.0, the best methods of building applications are still more art than science. But as the Ajax development tools mature they are falling into two general approaches that have far reaching ramifications for Web 2.0 software design, reuse, and adoption. Since these tools make architectural choices that can cut different ways with long-term effect, it means Web 2.0 software designers have to some weighty choices to make before they decide how to proceed.
One thing is clear from these tools though, Ajax has come into its own in 2006. More and more people are recognizing that it forms a true software platform for the Web. To demonstrate what's possible, the more mature Ajax toolkits, like General Interface, are actually entirely constructed in Ajax themselves. Thus Ajax is far more than an approach to Web user interaces; it's a complete software environment, something more akin to a Windows or Linux though far lighter.
Beyond the simple DHTML wizardry that allows an Ajax Web page to change in real-time before your eyes without reloading, Ajax has the ability to reach out and collect data from Web services (via server proxy). And it can help weave the results from multiple sources into composite software that folks are calling mashups. The whole mashup phenomenon heavily favors Ajax because of the power of JavaScript and XSLT allow the lightweight fusion of information right in the browser, making an Ajax application a sum greater than it's parts. This is partially what is meant by the Web 2.0 concept of software above the level of a single device.
For these reasons and others, Ajax provides key capabilities that Web 2.0 software needs. But depending on what you're trying to accomplish, you'll need select the right Ajax approach, and that's still the tough part. Web 2.0 isn't about technology in the end, but you will need it to build the software and you'll want tools that guide you down the right path.
As I spoke to Kevin and Dror yesterday it became clear to me that the approaches to Ajax are increasingly falling into two ends of a continuous spectrum. On one end we have full, self-contained frameworks that provide an integrated, and enclosing, solution and on the other there are lightweight Ajax pieces that can be included and woven together with other pieces. One of the Web 2.0 memes is small pieces, loosely joined, and this makes deciding between the comprehensive approach that General Interface, Atlas, or Backbase provide - versus more blendable solutions - a key pivot point in the design process.
Kevin Hackman, co-founder of General Interface, has himself has written about the trade-offs in the different approaches to using Ajax in The Four "Quantum States" of Ajax and he cited it in our conversation yesterday. But as I discussed the merits of Zapatek's newly announced Ajax Suite with company president Dror Matalan, he made it clear he believed that providing granularity and choice to developers was one of the biggest strengths of his product. Dror said his tools "go deep" but don't levy a complexity tax or vendor lock-in and can easily co-exist with other pieces.
Of course, different applications have different requirements. The larger Ajax tools will favor those who want a more traditional monolothic view of software or need more plumbing and infrastructure to connect to legacy systems, particularly behind the firewall. The smaller, more agile and inclusive Ajax approaches like script.aculo.us and Dojo will no doubt be much more popular on the greater World-Wide Web. I expect that public Web 2.0 software in particular will become an increasingly sophisticated yet loosely-coupled blend of snippets and lightweight Javascript libraries. Tools that don't enable this, much less support it, will probably have a harder time if they pose any barrier to adding compelling features to software.
And as people increasingly pick up on the vibrancy and utility of the mashups world, and we figure out better ways to locate them when we need them, the demand for software that is more malleable and easily changeable is going to increase. And here's the kicker: Web 2.0 software elements that can be recombined with a simple JavaScript include, like Google Maps, will succeed much more readily in this new remix culture over those that don't. Any solution that precludes such frictionless participation and reuse will just have an increasingly hard time getting marketshare. If there's one thing that we've learned in the last couple of years is that we should expect and encourage unintended uses.
Where do you think it's going? Small pieces that are quickly and easily composable, or sophisticated solutions that do everything?
Another sidenote: We're urgently seeking commercial Ajax authors for an exciting short-term project. Contact me for more details.links: del.icio.us
Personally, I believe that the future is divided. I have a large body of
web code that I do not want to re-write using a large monolithic framework.
I've been playing with prototype and scriptaculous to add interactivity and
'whiz-bang' to some of my pages.
Mark,
