Developing with next-generation Dynamic HTML

Asynchronous JavaScript and XML combine to enable powerful new capabilities for browser-based UIs

Last week I mentioned Greasemonkey , a Firefox extension that enables scripts to run in the context of Web pages. Since then I've written a few of my own Greasemonkey scripts. The first, which I've shown in a screencast, is an improved LibraryLookup.

With the original, you had to click a bookmarklet to jump from an Amazon page to a book's record in your local library. Now, if the book is available in the library, the Greasemonkey script automatically inserts an alert into the Amazon page.

As I discussed in the screencast, page rewriting is a hot topic that's about to go nuclear. When Google's toolbar added an AutoLink feature that can turn postal addresses and ISBN numbers into links, it rekindled the debate that forced Microsoft to withdraw its similar Smart Tags feature several years ago.

The issues are complex. When a page that doesn't link to Google Maps or to Amazon is modified to do so, the alteration touches on the interests of three parties: the author of the page, the reader, and the proprietor of the service to which the link points. From the author's perspective, an altered page can be seen as a copyright-violating derivative work. From the reader's perspective, it might be seen as deception, which is why AutoLink must be explicitly invoked each time it's used. From the service provider's perspective, it's great -- so long as the provider's service is the link destination; otherwise, it's not so great.

My new LibraryLookup script touches on the same set of interests, albeit in slightly different ways. In this case, Amazon is both the author of the content and the provider of the service. Notification of an alternate service, when available, benefits the reader and nobody else.

It's hard enough to think about this puzzle in terms of content. It gets even harder as content and services intermingle. Here's a message I hope I never see, but fear I might: “Service unavailable. Your browser does not support DOM locking.”

I'll let the lawyers chew on that one. Meanwhile, let's focus on how this technology can deliver the kinds of dashboard views that make hearts flutter in the enterprise. Until recently, I've used a couple of bookmarklets to gauge reaction to my InfoWorld articles, based on the list of bookmarks pointing to an article and the Bloglines summary of citations. Now, instead, I have a Greasemonkey script that counts these things and injects the counts into the InfoWorld pages I read.

You'd think these extra requests would slow things down. But because they're asynchronous, they don't. The script just fires off requests. When (or if) answers come back, it interpolates them into the page. Two components make this possible. One is the scriptable DOM, which enables in-situ alteration of Web pages. The other is the XMLHttpRequest object, which is now available in all the major browsers and which supports asynchronous interaction with remote services.

Combine the two and you get a powerful system for delivering real-time alerts in the context of Web pages. AJAX (Asynchronous JavaScript and XML) is the new name for this strategy, but it's an old idea, and XML is optional. At its core, this is about Web pages that communicate autonomously and update themselves dynamically. You'll soon see a lot more of these, and you may well find yourself creating some, too.

Copyright © 2005 IDG Communications, Inc.

How to choose a low-code development platform