Don't believe the (Web 2.0) hype!

Exciting times - or have we learned?

A large group is rallying around the web 2.0 bandwagon at the moment, somewhat reminiscent of the earlier web dot-com days gone by. Companies are buying out start-ups left and right, and there appears to be a lot of renewed interest and innovation going on in the bay area. I don't think it will be as big as some marketers would have us think, but there's no doubt that we'll see a lot of cool web-centric ideas, products and services come out of it - in fact, we already have.

But first, some whining.

Synergise your e-business deliverables! (laughingsquid.com) Pushing "Push Media" at the Web 1.0 summit: Synergise your e-business deliverables! (Photo courtesy of laughingsquid.com)

With all due respect to the industry folk who appear to be responsible for creating hype, excitement, interest and buzz around the Internet and its core technologies, I think recent history should be further analysed and considered whenever someone starts leveraging key business deliverables consistently across the web-enabled platform* , trying to come up with the next big buzzword that will revitalize turn-key developments. I still wonder if we've grown wiser following the results of the first big web bubble.

Let's go back to 1997 and recall a few of these Internet instant successes:

  • Micropayments
  • Push Media
  • VRML
  • Kosmo.com
  • Webvan
  • Spacer GIFs
  • Cue:cat
  • Sock puppet mascots

The above is a off-the-top-of-my-head mix of technologies or business plans (and in some cases for the latter, a lack thereof) which ultimately failed. Debates may continue over whether they were ahead of their time, a sham, not appropriate or just not profitable, but at the end of the day you are left with an idea or technology that didn't work. One would hope that we're smarter and have learned from experience in 2005, and can avoid much repetition.

Buzzword bingo (or, "bullshit" as a language?)

As a web developer and somewhat-technical person, I am familiar with most of the core internet technologies and am comfortable with saying things like xmlhttprequest or just plain old javascript, for example, in explaining the work I do. I don't really see the benefit in using hyperbole or euphemisims to say what I mean; rather than use "alternate" words to describe what you mean, why not just say what you mean? Skip the middleman and cut to the chase.

Revered comedian George Carlin has said in his skits, he doesn't like euphemisms or euphemistic language; he finds amusement in the fact that American English is loaded with euphemisms. ("Bullshit is everywhere, bullshit is rampant," he says.) Citing one particular example, Carlin explains that people no longer "die", due to fear of death: They now "pass away." Companies no longer fire people, they manage people out of the company. You know, "fired?" Management wants to curtail redundancies in the human resources area, having found that some people are no longer viable members of the workforce? Carlin ultimately attributes this to "Smug, greedy, white businessmen [who] have invented a language to conceal their sins, it's as simple as that."

It would be unfair to draw a line directly connecting death and lying to the "web economy", to be clear; rather, this is a parallel comparison of "using other words to generalise something," vs. putting a spin on things when they could otherwise be just described factually and without the masking, mystery or hype.

Create buzzword, blur definition/meaning, ???, (and if you're lucky,) profit!

I think most legitimate "web economy" buzzwords are conceived from an honest desire to consolidate and summarize the meaning of a potentially-valuable technology or process, particularly when trying to generate buzz or hype (and VC funding.) It appears to go downhill shortly afterwards however, as a large bandwagon effect shortly follows which pulls interest, questions and ultimately as in many cases, confusion around the definition and/or application of the technology at hand. This is the part that I'd imagine is most frustrating, since I think it devalues the purpose of the whole thing.

Oh AJAX, how I love thee

AJAX with a sense of humour (flickr.com) Great value! Apply liberally. Adds shine to any project. (I couldn't resist.. sorry.)

A recent shining example of buzzword coinage and resulting hype is Jesse James Garrett's javascript/XML web-centric "killer application" methodology, AJAX, which is not only a buzzword, but an acronym. (A buzzword made to mean other things, which has itself been shortened to a mere four letters! That's, like, double-compression or something.) It is perhaps no surprise then that with all this meaning packed into four short letters, the big question is this: "What is AJAX?"

AJAX is short for Asynchronous Javascript And XML** , which is "a web development technique for creating interactive web applications [using a combination of web technologies.]" Note that AJAX in and of itself is not a technology, but due to what I like summarising as "a few web sites and an article," AJAX and this "new" way of doing web stuff attracted a huge amount of interest in a short period of time.

Ultimately I feel because of all the interest, the definition of AJAX was and is still quite fuzzy. I met and spoke with Jesse James Garrett briefly at the recent counter-culture-type "Web 1.0" summit in San Francisco; Mr. Garrett seemed quite approachable and it was nice meeting him. I asked how he came up with the acronym, and he explained (if I recall correctly - this was at a pub, we were all drinking,) that he needed a catchy term to explain this technical javascript stuff to people who would otherwise be put to sleep by his talk about xmlhttprequest and xml. Apparently the term worked; Jesse explained further that following the presentation, he was asked what this AJAX stuff was about - "We Googled it and couldn't find anything." Thus, he had coined a new term and, justifiably, ran with it.

AJAX could likely be called "Web 2.0," and people would adopt the name due to its vague description. As described in Jesse's essay, AJAX includes XHTML, CSS, DOM, XML, XSLT and javascript; in short, all of the core client-side web technologies. Based strictly on the feature list, one could be talking about a browser at this point - not a methodology. It is this vague description which I feel is the primary reason for a lot of the confusion surrounding what AJAX is and is not, much in the same way the definition of "Web 2.0" and prior technology buzzwords are discussed and debated: Nobody really seems to be sure what's "in" and "out."

The new mouseover()

Web 1.0 dHTML!! (flickr.com) dHTML at the Web 1.0 summit, San Francisco

I recently sat on an informal web developer panel of sorts with a user interface/experience/design group, and AJAX was the topic of discussion. The design group believed that AJAX included things like animation and other UI effects, validation and a number of other scripted (but not necessarily XML-based) behaviours. This to me was a perfect example of the confusion around what this methodology was (some thought it was a language,) and is where I believe a key differentiator lies. If AJAX was "Advanced Javascript And XML" for example, I think it would have a somewhat broader application and would be more appropriate to the things people assume that it applies to. Given its current meaning is "Asynchronous" and is tied to XML/xmlhttprequest, the assumption is that it relates more to the use of the browser's xmlhttprequest object to send and retrieve XML-formatted data asynchronously (ie. while doing other things.)

In effect, I think AJAX is the new mouseover() - a script-driven, asynchronous browser action for which a result (eg. success/fail) can be retrieved, parsed and action taken upon. Granted, parsing an AJAX request is considerably more work than a mouseover() - but the interest and demand levels for AJAX are comparable to the mouseover() image-swapping craze of the mid-to-late 90's: Everybody was doing it - both well, and not-so-well.

Practical application

In my work as a web developer, I implement technologies such as browser xmlhttprequest objects and other scripted elements which would fit under the AJAX definition, but prefer to simply call it "javascript" or "DHTML", much like the folks both at Google and Yahoo! do in their products. Those who are less-technically-oriented are more likely to recognise and appreciate the "AJAX" term, having presumably heard about it at one point or another thanks to the buzz and industry coverage; that being said, most of this group are not sure exactly what AJAX includes - though they've heard good things and that cool things can be done with it. Thinking logically, usually that's all that one needs to hear in order to accept something. In my experience thus far however, almost all people who mention AJAX in discussions have later asked questions about its definition.

Where's my graceful degradation and accessibility?

While the AJAX methodology does not explicity mention graceful degradation and accessibility in its definition (again, this is not clear,) AJAX should be considered as a behavioural enhancement, a layer added on top of existing "classic"-type, "click and wait for the page to reload" code, not to be used as the sole method of access to core site functionality (eg. shopping.) Client-side javascript written to handle requests does not degrade gracefully to clients that do not support xmlhttprequest or script at all; a server-side or related degraded option must be provided if accessibility is important to you as a company.

Xmlhttprequest/AJAX also breaks the browser "back" button by nature, as asynchronous requests do not typically generate history entries. Workarounds for this are available, but are somewhat hackish and have less-than-ideal behaviour across the major platforms.

As it currently stands, many of the current cool, new and trendy AJAX applications appear to have little consideration for browsers and user agents without javascript or xmlhttp support. The Gap's recent redesign (gap.com) works nicely under IE and Mozilla Firefox, but fails under Safari despite having what appears to otherwise be fairly web standards-compliant code. Is this an AJAX-specific problem, denying a significant percentage of potential customers to the gap.com site despite their boasting of a "new and improved" experience to the other major browsers? This is reminiscent of the old Netscape vs. Internet Explorer wars: "This site best viewed in Internet Explorer. Only." Rather than allowing "non-supported" browsers to have a degraded but useable experience as in this case, clients are denied access to the site entirely.

Ideals

Here is what I hope to see AJAX, or just plain old javascript development, whatever you want to call it, evolve to:

Define, specifically, what AJAX is and is not.
"DHTML" (Dynamic HTML) was a buzzword at one time or another, and despite being still frowned upon by some has been accepted as a broad term that covers "HTML that changes after the page has loaded" and "doing stuff without reloading the page." A more-exact list of what AJAX does and doesn't do or apply to would help to clarify confusion, assumptions and expectations.
Pro-actively support and encourage graceful degradation and accessibility considerations in the AJAX methodology/spec.
While building for the new generation, it is becoming increasingly important not to leave out the remainder. Cell phones and other devices (let alone older browsers) do not currently support the core javascript required for AJAX to work; an alternate method of equal access (eg. traditional click-and-refresh) should be provided on all sites. The business case? Leverage customer base potential, maximise ROI.
Encourage use of XML APIs and standards-based communication layers for re-use by various services
eg. The degraded version of a site makes calls to the same XML API which your client-side JS calls, the processing being done on the server side for the degraded case. Bonus: Consistency of implementation between different views of the site, and less work in implementing both versions.

In summary

I enjoy writing script and developing nifty web things, "doing cool stuff in the web browser" and the like. Beginning in February 2005, the web development community has gone through a major surge in interest and activity; all of a sudden, it's an exciting, innovative and cool time to be working with client-side code again. While I may not like the idea of using a marketing-oriented term to refer to some of the technology I've been working with for years (and it's tempting to mock some of the marketing-ese,) I can appreciate the usefulness of being able to quickly communicate the value and application to someone less familiar with the technology without having to explain all of that nerdy mumbo-jumbo.

Wherever this web 2.0 stuff goes, I hope it continues to encourage innovation and development of cool new stuff in the browser space. Ultimately that entails the work that I do, and I'm currently having a blast doing it. The renewed interest in javascript has given me opportunities to work on some really fun things. Given the choice I'd probably give "web 2.0" a different name as well, but I'm not the one calling the shots on the internet - I just work on the thing.

I'm looking forward to the times ahead. Sit back, relax and enjoy the show; it should be a lot of fun.

Damn, this is a rant!

* Mentally re-phrase with finger-quotes a la Doctor Evil, eg. "laser beam."

** Further amusement: the "X" in "AJAX" is short for XML, which is short for eXtensible Markup Language. Not to worry - you'll be a pro at this acronym stuff in no time.

Related links