Life After Ajax?
June 29, 2005
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.
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
addressing and the actual properties to set throughout the XML tree. XForms Map
Viewer again makes use of the dependency engine.
If you're more into code examples, an earlier article on XML.com 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.
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.
Births, Deaths, and Marriages
Featuring a grid view and XSLT 2.0 debugger.
Conference wiki launched.
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