Life After Ajax?

June 29, 2005

Micah Dubinko

With every passing hour our solar system comes forty-three thousand miles closer to globular cluster 13 in the constellation Hercules, and still there are some misfits who continue to insist that there is no such thing as progress. —Ransom K. Ferm

I'll begin with a small confession: I have a thing for crossword puzzles. I always fill them out in pen, not because of some intellectual machismo, but simply because I have lots of pens around, and few pencils or erasers. Working on a crossword puzzle with ink means two things: you find yourself more conservative, (You wait until you are fairly confident before committing to something.) and when you inevitably make a mistake anyway, it gets messy to patch things up.

Software development is the same way. No matter how carefully a developer proceeds, at some point a mistake will happen, and if the erroneous code has gone out the door, you have a messy situation that needs patching. At that point, software can begin to look like a badly scribbled-out crossword. Depending on the location of the error—whether it's in a fundamental API or just an implementation detail for instance—external developers can be affected as well, making their code messy too.

But from another angle, software development isn't like crossword puzzles at all. A crossword has a single canonical solution. Software, besides being vastly more flexible, normally doesn't have a single canonical "solution." Excepting for narrow cases involving intellectual property lawyers, the existence of a software project is normally a good sign that the team is attempting to do something that no other group has done exactly. The potential for creativity is a major draw for many practitioners of the software craft.

The other difference between crosswords and software is that with the latter, the problem itself can change as you work on it. Different pieces can fit together in different ways over time; often developer attitude is the only obstacle. I wrote previously about how Google and others have helped people capitalize on the power behind a set of technologies now known as Ajax, though they've been available for years.

Some of these technologies, though, are fragile. Someone recently asked me if he could use my base64 JavaScript from The Endecoder for one of his own OS X Tiger widgets, because, "Google changed the authentication system for the Atom RSS feed that drives the widget, and it stopped functioning. Getting around this problem required base64 encoding the username and password."

Contracts, Promises, and Dependencies

The problem, in a word, is contracts. In a web application, which parts are guaranteed not to change? Which parts are fair game? What will remain backward compatible, and what will be forward compatible? When things do change, what kind of advance notification process is in place? All of these (and more) are thorny questions that need to be dealt with. Users of Greasemonkey, a Firefox plugin that allows script-driven customization of individual pages, were also seen complaining recently, as that same round of changes to GMail altered certain internals that broke their customizations. Conventional applications tend to have crisply defined APIs, given in header files or something like JavaDoc, with autocompletion provided in your favorite editor. In web applications, the lines of responsibility are much blurrier.

If that's not bad enough, the recent move towards Ajax technologies has diluted the potency of core markup. A smaller proportion of HTML files today is devoted to intention-carrying markup, with a larger proportion toward fragile scripting. So far, the problem has been one that sharp programmers have been able to solve, but before too long the building will need a better foundation to avoid collapsing under its own weight.

Recently, Mark Birbeck, in his weblog Internet Applications has been focusing on the "next generation" of web applications, in particular recreating a number of nifty Google web applications using technologies like XBL and XForms. A common theme in Mark's postings is the use of Sidewinder, a web applications toolkit bundled with the preview release of the IE-based XForms engine Mark's company produces. Our main interest lies not in the specific technology as much as in figuring out the general direction that web applications might take in the future. For example, in XForms Patterns: Incremental and 'Google Suggest' Mark looks at the way Google Suggest works, and proposed a few changes to make it more declarative and XML based.

Other posts go farther down this path. CSS, the XForms Dependency Engine, and 'Dynamic Infosets' provides a comparative analysis of CSS selectors versus the XForms bind element. Yes, they are very similar, both providing what he calls dynamic infoset capabilities, but the XForms version works better in web applications because of the greater separation between addressing and the actual properties to set throughout the XML tree. XForms Map Viewer again makes use of the dependency engine.

Higher Levels

If you're more into code examples, an earlier article on highlights the difference: a procedural script author needs to analyze the situation to determine all the possible entry points that can affect a changing piece of data—missing any will result in tough-to-spot bugs. By contrast, declarative programming states the desired outcome and lets the system take care of the details. A higher-level approach to the problem is easier to create and maintain.

The push for higher levels goes well beyond web applications. A look through job boards will show that development increasingly occurs on higher-level, garbage-collected languages like Python, JavaScript, C#, and Java—again letting the system take care of the details. In lower level languages, authors need to carefully analyze allocation and freeing of memory; any mistakes will result in tough-to-spot bugs or memory leaks. To an extent, a higher-level language frees the author to think about solving more meaningful problems.

Note, however, how carefully I am avoiding the word "abstraction" here. Adding a new layer of abstraction is a favorite tactic for many programmers, but the more layers, the more leaks. No, the higher levels I'm talking about are more deeply integrated and fundamental than mere layering.

There's no doubt that clever programmers are comfortable with the status quo, and will be able to keep doing more and more amazing things with JavaScript and Ajax. Previously I argued that "Smaller, focused teams will be able to accomplish great things." Spoken like a true consultant, I guess. But to alter an old programmer's saying, debugging Ajax code is twice as hard as writing it, so anyone who writes clever code may not be smart enough to debug it. The result is upwards pressure toward more declarative technologies. So while the overall pattern of Ajax will continue, expect the means to accomplish it to become more elegant. In the immediate future, though, expect to see heavily-scribbled crosswords.

Births, Deaths, and Marriages

Exchanger XML Editor 3.1

Featuring a grid view and XSLT 2.0 debugger.

Extreme 2005 approaches

Conference wiki launched.

Last Call for UBL Input Specifications

July 1 is the last chance to comment on the developing specification for creating UBL forms.

Documents and Data

Lean times on xml-dev: Week of June 12-18: 11 messages. Week of June 19-25: 49 messages

U.S. Federal Government's Data Reference Model (DRM) XML Schema