Is AJAX really the next big thing?

I woke up this morning and realized to my surprise that it's been about ten years since Apple cancelled its ill-fated OpenDoc project. The cancellation of OpenDoc led directly to the creation of the first version of Verdantium, and ten years later I'm still not finished with it.

Ten years is a long time in the technology field. OpenDoc, even after all of this time, still seems ahead of its time. OpenDoc's concept of small cooperating visual components still does not seem to have been replicated by any popular mainstream framework. Nevertheless, I have thought about Verdantium's future. One one hand someone could argue that Verdantium is a really quaint JFC/Swing system that has been outmoded by the new shift toward Web Applications, Asynchronous Javascript and XML (AJAX) and Service Oriented Architecture (SOA). On the other hand, Verdantium's still seems to suggest a utopian future software architecture rather than a prosaic replay of the past.

There are some projects that the new AJAX web applications do well, and there are other projects that they don't seem to do well at all. Google Documents seems like the ultimate blog creation system rather than something that could overthrow office applications like Microsoft Word. The Google system ignores the printed page-- there's no page view, no print preview, no headers, no footers, no table of contents generation, no settings for different printer page sizes (e.g. A4), no color matching, no kerning, etc. Supporting all of this would require two things: first getting printer information to the network server, and second sending lots of bitmaps over the network in real-time. The second of these is likely to be prohibitive compared to Microsoft Word running in Page View. All of the bitmaps probably won't cross the network fast enough.

In spite of the hype about AJAX-based office applications running on a thin client, it's hard to imagine an AJAX-enabled word processor replacing current desktop software. And that's just the word processor. What about image processing? Would anybody want to use the equivalent of Photoshop over a network pipe?

I think the dominant productivity applications of the future are still going to run very thickly (as in thick-client or typical MS-style office application) on the CPU of the end-user's PC. But at the same time, I think it is possible to have a paradigm shift in how those applications are created.

In the currently dominant office applications Microsoft Office, Corel Ofice, Star Office, etc., there are a small number of enormous monolithic container applications (Microsoft Word, Microsoft PowerPoint, etc.) that embed smaller custom components (e.g. JPEG Movie Players) through protocols (e.g. Microsoft OLE/Active-X). This is counterproductive for both users and developers. Users can't mix and match components as they see fit. Developers don't have options for collaborating.

Imagine a framework where one could create a custom productivity suite by rolling together a large number of very small components through a protocol. No dominant office application-- just a protocol. That was what Apple originally proposed with OpenDoc, and even today it still seems like an exciting idea. Leverage each developer's particular skills. Have each developer write a small component in the domain she knows. Don't try to write a huge containing application, but instead provide a way for many smaller components to work together to create the equivalent of a powerful office suite.

Ever notice that it seems hard to write container applications in Microsoft OLE and Active-X? Of course it is. A lot of small, utilitarian container applications embedding each other could gang up on Microsoft Office.

In Verdantium, I tried to make it especially easy for developers to write container applications. In fact, anybody can write a container component supporting multi-level undo and scripting in a few hundred lines of code. In fact, there's a package in the Verdantium download on Sourceforge called MyContainerApp that gives a fully coded example of this. One who looks through the Verdantium source code long enough will find several other examples. I still think this is relevant post-AJAX.

The Verdantium undo system seems much more advanced than the other undo frameworks I've seen. It's more advanced (and faster) than trying to roll back a relational DB. It's more advanced than the system Sun has in the Swing APIs (which uses the inverse command pattern). It's more advanced than what Apple used to ship with OpenDoc. I am not aware of any Java-enabled open-source framework that is providing a temporal undo capability. I'm not aware of any web application frameworks for doing this, either. Temporal undo is highly advantageous for keeping the self-consistency of the multi-level undo implementation high while keeping the SLOC count (and hence the number of bugs) low. People like small, powerful components that are bug-free. Did I mention that multi-level undo is a capability that many Microsoft Office users ABSOLUTELY REQUIRE? That is to say, they will NEVER switch without it.

I think there is a point to all of this in the post-AJAX and post-SOA world. As computers get faster, there will be a point in the future where a Java-enabled system such as Verdantium will be "fast enough" compared to the current productivity suites. Verdantium will get there long before AJAX does (if AJAX gets there at all). Time is still available because technology hasn't yet advanced to make either alternative fast enough (yet!). "The future" could still happen.