HolidayBuyer's Guide

Will Ajax help Google clean up?

Google's popular map and e-mail sites reignite interest in older Web tech, raising potential threat to Microsoft, Flash and Java.

In the race to build the Web of the future, some developers are reaching back to the past.

Start-ups and industry giants such as Microsoft continue to devise newfangled systems for delivering desktop-like applications over the Web. But search giant Google has taken a different path, using older technology to build its newest applications such as Google Maps and Gmail.

That's prompted developers to take a second look at old-hat technologies that have been kicking around on the Web since the 1990s, such as JavaScript and Dynamic HTML.

News.context

What's new:
Google's popular map and e-mail sites have reignited interest in old-hat technologies that have been kicking around on the Web since the 1990s.

Bottom line:
If technology that works in the current generation of Web browsers is indeed good enough for powerful, scalable Web-based applications, it could be a potential threat to Microsoft, Flash and Java.

More stories on this topic

"Suddenly you've got a company like Google that has shown to a mass audience that rich Internet applications have a tremendous benefit to the end user," said David Temkin, chief technology officer of Laszlo Systems, a start-up whose Web application system underlies EarthLink's new e-mail Web site. "The difference between Google Maps and any other map site is not subtle--it's almost a different product category. And the same is true of Gmail."

Those older technologies--such as the JavaScript scripting language, the Cascading Style Sheets recommendation by the World Wide Web Consortium (W3C) for applying styles to multiple Web pages, and other coding bells and whistles--are sometimes grouped under the marketing term Dynamic HTML, or DHTML.

The interest isn't driven by some dot-com nostalgia. Proponents argue that these older technologies are good enough to do the job and that support for them is already embedded in common Web browsers.

Developers have filled their blogs with debate over a recent Feb. 18 posting by Jesse Garrett, co-founder of San Francisco consultancy Adaptive Path, who coined the acronym Ajax to promote the idea of using "Asynchronous JavaScript + XML" as a way of building Web applications with freely available technologies.


Bloggers have nitpicked at the term, and Google engineers refer to their coding technique simply as JavaScript. But in just a month, "Ajax" has gained currency with the recent flurry of blog postings and a story about it in The Wall Street Journal.

"While I'm not usually a big fan of new acronyms, I'm happy to see this Ajax idea emerging," said Toni Schneider, product manager in Yahoo's platform engineering group and former CEO of Oddpost, which Yahoo acquired last year. "Someone's given a name to what we've been working on for years, to the idea of using JavaScript and moving it to the next level."

If technology that works in the current generation of Web browsers is indeed good enough for powerful, scalable Web-based applications, that could result in reduced demand for everything from Laszlo Systems' tools, Macromedia's Flash and Flex-based offerings, Sun Microsystems' Java-based applications, and for Microsoft's planned system based on XAML (Extensible Application Markup Language) and Avalon graphics.

The stakes are especially high for Microsoft, which for the past 10 years has had to contend with the Web as a potential threat to its core operating system and desktop applications businesses.

The software giant, which pioneered several of the technologies developers are now re-evaluating, dismissed any threat to its plans for XAML.

"It's a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century," said Charles Fitzgerald, Microsoft's general manager for platform technologies. "But XAML is in a whole other class. This other stuff is very kludgy, very hard to debug. We've seen some pretty impressive hacks, but if you look at what XAML starts to solve, it's a major, major step up."

So which is easiest?
One area of debate is whether JavaScript and other DHTML technologies wind up making development easier or more complex than newer systems over the course of an application's lifetime.

Some purveyors of alternate methods point out that HTML was designed to build hypertext documents, and is now being jerry-rigged to create interactive applications. That, they claim, results in more development difficulties and compatibility issues, a harder quality assurance cycle, and the absence of prefabricated, higher-level building blocks.

"It is really, really, really hard to build something like Gmail and Google Maps," said David Mendels, general manager of platform products for Macromedia. "Google hired rocket scientists--they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can't go and repeat what Google has done."

That level of difficulty might explain why it's taken until 2005 for some 1990s-era Web technologies to become more popular, said Peter O'Kelly, an analyst with the Burton Group. Renewed interest is "partly because of some clever approaches that have been recently exploited and partly because it has been exceptionally difficult to master the underlying technologies," he said.

"Google hired rocket scientists...Most companies can't go and repeat what Google has done."
--David Mendels, general manager, Macromedia

It isn't just Google advocating the blast-from-the-past approach. Sentiment in favor of status quo methods erupted into a schism within the W3C, where a splinter group called the Web Hypertext Application Technology Working Group (WHAT-WG) rebelled against the W3C's XForms vision of Web forms--a crucial component of Web-based applications--and drafted its own specification to standardize currently widespread techniques.

That consortium of browser developers--including Apple Computer, Opera Software and the Mozilla Foundation, whose working group representative Brendan Eich invented JavaScript--is also developing a Web application specification geared toward stitching together JavaScript, HTML, CSS and the W3C's Document Object Model for letting scripts act on individual parts of a Web page.

The group formed last year in part to respond to the potential threat posed by Microsoft's plans for the proprietary XAML/Avalon Web and Windows application coding system that, if successful, could marginalize standard approaches.

"Microsoft published an outline of what they were trying to achieve, which is using markup languages to build applications," said Hakon Wium Lie, chief technology officer at Opera Software, that company's representative on W3C's advisory committee, and a WHAT-WG founder. "We thought we could do the same thing with existing Web languages. People were writing applications like Amazon and Hotmail and Google search, so why not have a specification for it?"

One benefit of working with JavaScript and HTML, say proponents, is the preponderance of experienced developers as compared with Flash developers or specialists in other systems. Flash, while widely distributed, isn't as universal as a Web browser, and some developers say their clients fret about Flash-incompatible firewalls.

Some developers mix and match. The popular online photo site Flickr, for example, uses Flash for some tasks and JavaScript for others on the same page.

Passing fad?
Technologists working on the next generation of Web application technologies scoff at the idea that a JavaScript renaissance is going to threaten their vision of the future. Instead, they insist Google's rising tide is lifting their boats.

"For a company serving that many people at that scale, Google is taking uncharacteristic risks on their front end to do things that other companies with old infrastructures in place don't know are even possible," said Laszlo's Temkin. "I'm incredibly happy that Google is taking this step, because it's forcing the market to realize what to us has been incredibly obvious about rich Internet applications. It's forcing the portals and others to notice the value here. That's tremendous for us."

"Google is taking uncharacteristic risks on their front end to do things that other companies with old infrastructures in place don't know are even possible."
--David Temkin, chief technology officer, Laszlo Systems

By the same token, Google denies any ideological attachment to its standards-based approach. Instead, the company says it has evaluated all the options before it and will continue to do so as new technologies become available or existing ones get refined.

The JavaScript approach, Google acknowledges, leaves some things to be desired. For example, it's harder to integrate applications with third-party applications.

In the final analysis, however, Google has given JavaScript that crucial programming designation: good enough.

"We've considered these other things, and we've talked about some of the other options, but thus far the technologies haven't gotten to the point where we feel the need to switch to them," said Paul Buchheit, the Google engineer who spearheaded the Gmail project.

"If something like Avalon or Mozilla's XUL (Extensible User Interface Language) were to become powerful and common enough, that would be interesting to us," Buchheit said.

Ultimately, any push away from JavaScript and other DHTML technologies may stem less from the improvement of other options than from the demands of the applications.

"Google is a first step or second step, not an end point," Temkin said. "The successors to Word and Excel and Powerpoint are not going to be written this way. It's just not going to happen."

Close
Drag