Life After Ajax?

by Micah Dubinko
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.

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 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.

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.

Schreibe einen Kommentar

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s