This talk was prepared in advance for the XTech 2006 conference.
Copyright 2006, Alex Russell, All Rights Reserved
-----------------------------------------------------------------------------

Good Morning,

I'm Alex Russell, Project Lead for the Dojo Toolkit and I currently serve as
President of the Dojo Foundation, which means I as in the wrong place at the
wrong time and apparently dumb enough to say "yes".. 

As you are probably aware, Dojo is an Open Source JavaScript toolkit under a
BSD license. It builds abstractions to make JavaScript development easier and
backs them up with tested, pluggable implementations.

While I could drone on about Dojo for hours (and have), the world suffers
enough at the hands of marketers.  It'll be a sad day when Open Source projects
start adding to the pile. I'll talk more about Dojo later, but only after we
get a firm idea of what the broader problems we're trying to solve look like.

But first, I'd like to draw some attention to the tremendous social hack that
is the word "Ajax". It's really an amazing thing. Two years ago when we started
the Dojo project, those of us who admitted to writing JavaScript with a
straight face were either pitied or scorned. Which made sense when you consider
the tools we had to work with. Browsers are not hospitable places for
developing applications and many hackers considered JavaScript a toy to be
dismissed.

Today companies can't get four Ajax devs with 10 years of experience fast
enough. And no excuses! They need the best! Who cares what they need them for,
their blog-driven, tag categorized, wiki-backed, e-commerce alpaca sock store
needs ajax! stat!

Oy.

About couple of months ago I had the ghastly experience of attending a
conference called "Software 2006", and aside from an insightful discussion on
the geopolitical and economic implications of technology trade with China, it
was a conference of old ideas with new buzzwords attached.  The word "Ajax" was
used freely as a proxy for anything having to do with a browser-delivered app
and words like "web2.0" and "folksonomy" where bandied about in a marathon game
of bullshit bingo. I even heard the word "wiki" get verbed before my very ears.
When the marketing folks from enterprise software companies start calling a
buzzword thier own, we're clearly at the apex of a hype cycle.

And the tech press isn't helping matters! I haven't seen a feeding frenzy like
this since XML was "the new EDI"! To hear the tech rags tell it, Ajax may not
have been *intended* to cure cancer, but it just might anyway. And the reason
no one can tell you whether or not it will is that the word "Ajax" doesn't
*have* a meaning. At least not one that more than two  people agree on. 

Oh, they may *think* they agree on the definition, but if you show people
applications that have been billed as Ajax, you rarely get a straight answer to
the question "is this Ajax?" 

For extra confusion, attempt to get agreement on whether or not that same
site:

	a.) is web 2.0
	b.) can be "web 2.0" without ajax
	c.) can use ajax and be "web 2.0" without tagging

Clearly Ajax describes a phenomenon that was naturally occurring and missing a
compact moniker, but the great invention of the term Ajax is that it is
implementation-independent, and therefore, amorphous. There's nothing you can
point to and say "this is ajax and anything that isn't this, isn't Ajax". 

There is a creeping definition scope.

So we can't get a definition of Ajax by acclimation or example, but perhaps we
can get some sort of boundaries around what *isn't* Ajax? Clearly the Google
home page doesn't qualify, whereas GMail does, but what about sites built
entirely in Flash? Or XUL? 

I think most people would say "no, those things aren't Ajax", but even going
that far requires some expanded definition from Jesse James Garret's original
article. Lot of things are being called Ajax that have very little to do with
background data transfer.  I'll address why that might be the case later, but
right now we need a better definition...or at least some sort of test that we
can apply.

Being foolhardy as I am, I'll jump right in and propose a test for "Ajaxyness".
Like the term itself, it's necessarily a fuzzy thing with room for
interpretation, but it comes down to whether or not an app's users, in
aggregate, have to care or are made aware that they're not interacting with
isn't their native browser.

When taken over a skewed sample set, this test could give cover to any number
of non-native and non-portable technologies, but the word "aggregate" allows us
to capture that the definition relates to users and not particular techniques.
Is a DHTML app augmented with Flash in the background for audio an Ajax app? If
users never have to know or care there there's Flash involved, this test says
"yes". If, on the other hand, the site makes users download some particular
version of some plug-in or use some specific version of some browser then the
answer would clearly be "no".

Coming from a web application security background, I like tests that deal with
how a system fails instead of how it usually succeeds, and while I expect to
take a lot of flack for this definition because it's so loose, I'll put it out
there for rebuttal in the hopes that we evolve something better.

Regardless of definition, though, I think that "Ajax" is perhaps the best
language hack in programming since Jeffery Zeldman co-opted the phrase "Web
Standards" and started bludgeoning everyone who would listen with well-written
articles and tastefully illustrated tomes about how their websites sucked.

Of course, that's an exaggeration. To the best of my knowledge neither Zedlman
nor Jesse James Garret have such binary views of the respective topics.
Fortunately, there's no subtlety that continued distillation and repetition
can't remove. Like "Web Standards" before it, "Ajax" is now a hot-button topic
with the "haves" shaking their heads in slight pity at the "have nots".
Perhaps these things get turned into polarizing, under-defined hand-grenades of
language because it's entertaining to imagine Zeldman or JJG with a monocle and
hairless cat. We love nothing more than the creation of narrative where only
ambiguity really exists and nothing short of outright lying does it faster than
excising context and detail from the discussion. Besides, it makes for a better
"anti-patterns" book if you can create a straw-man to knock down.

But for a meme to really take hold in our acronym-laden frontal lobes, a thing
has to have real importance and I think that the crux of both "Web Standards"
and "Ajax" can be summed up in the word "available". In fact, I suspect we can
trace the whole history of the web back to the word "available", and plot Ajax
along that trajectory. Doing this should let us get a better idea of what is
coming down the pipe next, or at the very least the properties that such things
might have. Therefore, I assert that Ajax is evolution, not revolution, and
that it is part of a continual evolution that is more important than many of
the supposedly revolutionary web technologies that we have endured along the
way.

The history of the net is a triumph of information access. From the earliest
research reports in a format that allowed simple cross-linking to get more data,
to today's search engines which catalog and rank the now myriad sources of data
on any topic to, not least, the applications which are every-increasingly
losing the shackles of their desktop embodiment the web has walked into every
silo'd market it has been reasonably able to compete in and trounced the
previous generation of applications that served the same market, if in a
different way.

Before I dropped out of college I had access to one of those "all the Microsoft
software you can eat for 5 bucks a CD" programs that are the software
equivalent of the credit card sign-up stands dotted around campus on the first
week of school. 

Handy in places, but you get the sneaking suspicion that it's gonna bite you
later on. 

Unlike the credit-card booths, though, I took full advantage of the monopoly
market segmentation that was working in my favor. Perhaps the best ten dollars
I spent in 1999 was on something called Microsoft Streets and Trips. 

It had this amazing interface that let you zoom in and out of any area of the
United State, ask for directions from one place to another, and best of all, it
let you see all kinds of local data from attractions to places to eat. 

It was a true "holy shit" moment.

The first time I planned a cross-country trip with it I realized how important
it was. Mapquest had nothing on this. Perhaps as a quaint throwback to a
simpler time, Mapquest still doesn't but luckily for us other services have
evolved.

Today Google and Yahoo Maps deliver the same "holy shit" experience to everyone
with a browser. Instead of installing gigs of data to a local disk and then
updating changes intermittently, these apps trade away some responsiveness for
the ability to be deployed into the most ubiquitous app platform ever devised.
Sure, some esoteric features are missing, but in return I get aerial photo
overlays and the ability to send a link for any place in the country to anyone
else. 

Some day I'd love to see the sales data for retail or after-market copies of
Microsoft Streets & Trips over the last couple of years. I suspect that
web-delivered apps that are only "good enough" have had the same affect in this
market as they have everywhere else. 

Availability trumps technical superiority.

Hell, even MSN now has a web-based mapping service, and it beats the living
crud out of what you could get out of Streets & Trips back in The Day (TM).

But before we had the newly-trite examples of Ajax-enabled mapping and tagging,
the web was pushing apps into the hands of many at the expense of some
responsiveness. The key has been doing it at a cost to users (generally, free)
that was simply unapproachable before. 

When put that way, the idea that web applications make things more available
seems pretty obvious. Web apps have advantages that we can all recite like some
kind of web developer scout motto:
	zero install
	no client upgrades
	centralized administration
	and platform independence
It's old news and Ajax just continues the trend. It imbues new classes of
applications with the same advantages and allows us to make old web apps even
more compelling. 

Using the world "revolution" does seem a bit silly, doesn't it?

But that word persists. I actually consider the lack of revolution to be
fantastic news. Revolutions have a reputation of being short, bloody affairs in
which the outcome is largely unpredictable. 

The ones that succeed and get co-opted by magnanimous and fore-sighted leaders
have holidays named after them. The ones that don't usually wind up with the
words "insurgent", "dictator", or "attempted coup" attached to them. 

The later greatly outnumber the former. 

And so it is in technology. Revolutionary technologies create opportunities for
the exercise of monopoly control. As luck would have it, the web has escaped
the death grip of single-vendor control through a history of active, if not
always legal, competitive chaos.

By evolving several key text-based, open, layered, and royalty-free standards
over time and by continued improvement in implementations, the web has
demonstrated tremendous resiliency to centralized control.

It's this independence from single-vendor or single-implementation domination
that has driven the peaceful, if not pretty, evolution of web apps. 

I think that we can then also assume that the web will continue to improve in
much the same fashion, with many of the same results in new market segments.

Think of a desktop app that you use today that you think can never be delivered
via a browser. I know it's a short list, but try to come up with one. Now strip
out some level of responsiveness and UI flexibility and re-imagine it with a
location bar at the top and forward and back buttons.  Cool, huh?

It's safe to say that a lot of the things you'll need aren't natively in
browsers today, but even if they were, what's to say we'd be taking advantage
of them? In light of the lag between the introduction of the underlying
technologies of Ajax and when they finally "hit the big time", I think it's an
important question. What took us so long?

Like the technology platform itself, evolution happens in the development
community, driven partly by market demand and partly by knowledge
dissemination. 

Does anyone remember AlphaBlox? 

They developed DHTML spreadsheet and presentation tools at the turn of the
century that today's Web 2.0 attempts haven't even begun to rival. But they
were IE-only. Same with WebOS.com.  Amazing code, incredibly capable, and only
now starting to get re-created. 

The important difference between today's contenders and the attempts of yore is
that today if an app doesn't support at *least* IE and Firefox, it may as well
not exist. Extra whuffie is awarded if an app supports Safari or Opera as a
first-class citizen.

The difference is in what it means for your application to be "available". It's
not when one browser introduces something that it becomes "available", it's
when competition drives it into every desktop and OS via competition in browser
features. 

The importance of Firefox as a platform that implements web standards
more-or-less fully can't be overstated. In a world where your application is
freed from it's desktop confines by browser delivery, being able to deliver
across browsers *is* being cross-platform. It's not to say that a lot of these
things weren't possible on earlier versions of Netscape browsers, just that
they cost too much to attempt. 

Building software is a negotiation, and the tools that are truly available to
developers are the ones that meet their time, resource, and knowledge
constraints. Ajax is ascendant today because while we weren't looking, what had
previously only been *possible* with JavaScript became *available*; mostly
because browsers now meet the same cost reducing mile-markers for scripting
that regular HTML and CSS markup passed in the last decade. 

Instead of having wildly divergent syntaxes to accomplish the same things,
browsers now implement the same APIs...mostly. Perhaps even more importantly
though, they all now support many of the same fundamental capabilities, and
since this can be scripted, we can start to provide coherent interfaces on
those bits that may not yet be in perfect cross-browser harmony. Requiring that
things be written twice is rarely a recipe for success in a platform. Making
the same thing available everywhere, is.

This process of improving browsers and pushing adoption has been, and continues
to be, ugly. Server-side platforms, browsers, and applications all sport a
number of vestigial features. Evolution is rarely pretty or straightforward.

Interestingly, a cultural shift in the web programming community at large
toward dynamic languages seems to have also improved the acceptability of Ajax
as a way of getting things done. Sadly, there are still tools today that
attempt to present JavaScript as though it were something it's not, but I think
that's surrmountable as more and more people dig into the power of the
language.

JavaScript has, for a long time, been both derided and feared as a strange
little language that's never quite what it seems. While weird, the language
itself is tremendously capable and infinitely flexible. With concepts from
functional programming such as closures starting to permeate the mainstream,
today's web programmers finally have mental models to grok why JavaScript feels
so weird. 

Comparing JavaScript to Java or C++ has always been like converting Unicode to
ASCII by lopping off the high bits. 

Fortunately, comparing JavaScript to PHP, Python, Perl, or Ruby at least allows
you to discuss how one expresses same ideas in differing syntaxes. In a sense,
we had to wait for fundamental programming knowledge to become available.

While the browsers were stabilizing, something equally important
happened to the applications themselves: 
	We got standardized of interaction metaphors. 

In 1998 it was unclear that tabs would be a workable interface idiom, but
now that Amazon and Salesforce have made them de-facto standards, there is less
high-profile experimentation around navigation metaphors for segmented sites
and applications. 

For better and for worse, we needed the wild west of interaction and
information design to get a handle on regular old HTML and CSS before chewing
off the new axes of design choice that JavaScript enables.

Introducing a Turing-complete language into the design process before the
ground-rules are laid down led to much bad aping of desktop idioms. The web has
unique construction primitives and some very non-portable concepts of location,
state, and content constraint. Working at odds with these leads to applications
that don't "feel webish". It took a long time to convince DHTML hackers that
re-inventing the scrollbar with quirky, non-native and obviously non-standard
behaviors might not be a fantastic idea.

Many desktop metaphors break when presented with web constraints. A back button
or the idea of bookmarkability are foreign to traditional apps. Even when they
can be designed for, the tools need to support these requirements. The failure
of JavaScript for building UIs in the late 90's is due in part to a lack of
appreciation for these intrinsically "webby" properties. The evolution to
understanding them was painful, but it's paved the way for the improvements in
user experience that we now shove into the definitional grab-bag that is
"Ajax".

What I'm getting at is that while it probably could have happened a few years
earlier under more ideal conditions, the explosion of interest in Ajax makes
perfect sense when taken in context. It probably *couldn't* have happened in
the late 90's. We just weren't ready. We hadn't mined HTML and CSS for
everything they could do.

Now that we have, it's great having a single term that allows us to put the
evolution in all of these areas, browser, developer, and designer into a handy
contextual container for better portability. It's no surprise then that the
term is being used to describe everything under the sun that has anything to do
with JavaScript in a browser.

In one sense, the term "Ajax" is being used to denote an improvement in the
expressiveness of web applications. The construction of interfaces is
constrained on all sides. Without expressive design, great technology can go
under-used, or worse, over-used. 

Without expressive technology, designers are forced to make compromises that
hobble the user experience. And without good tools and a solid platform to
deploy on, businesses can't pursue more ambitious projects that can give them
an edge over their competition or commoditize a legacy desktop system.

Better primitives for expressing things ultimately lead to different things
*being expressed*. Today the market is exploring the capacity to express all
kinds of things in browsers that were once off limits, but I worry that in the
frenzy we will miss the important less of the evolution that got us that far:
namely that we're going to fail most of the time. Like the first draft of a
book, the threads of application and platform expression are likely to lead us
in directions that will also make sense in hind-sight, but probably aren't easy
to divine from where we are today.

But the web that's unencumbered by single vendor or single implementation
control, what I call the Open Web, is now lurching forward once again. The
standards bodies have been rousted from their premature slumber and the browser
vendors are once again throwing everything they've got into a renewed browser
arms race. And that creative chaos is exactly what we need right now.
Unfortunately, improvement in basic browser capabilities doesn't become
"available" in the broader sense for roughly half a decade.

If that sounds like a long time, ask yourself "when will I be able to not
support IE 6 when building a new webapp?" OK, so maybe half a decade is
optimistic. But regardless, today's browser API chaos is tomorrow's new
platform capability.  And if the last evolutionary cycle in web apps is any
guide, it'll take us that long to figure out how to best use the new stuff it
provides anyway. 

But that isn't to say that there isn't room for improvement in how we build our
apps until then. There are plenty of veins to be mined for expanded
interactivity in the browsers we have today. In the same way that great
reporting is usually the case of close reading fine print, great reponsive web
development today tends to involve quality time with MSDN and Mozilla's lexer.

Of course, browser upgrade cycles are a bittersweet thing. Just when you've
learned every trick about one renderer, all of that trivia becomes useless.
Someday I'm going to have to figure out a way to reclaim the space in my brain
dedicated to DHTML workarounds for IE 5.0, but even if I never do I'm quite
happy to have IE 6 in it's place. But there were capabilities even in IE 5.0
that we aren't yet taking advantage of.

I'd like to digress for a moment to talk about the danger of tech evangelism.

First, it should be noted that I write Open Source software for a living. I
don't think that's a job that you can get without in some way believing that
what you're doing is somehow good for the world. 

But there's a line between having the best interests of users and developers in
mind and staking out a set of concrete technical positions regarding a changing
playing field like web application development. While this talk is about the
Open Web, and while I've blogged in the past about things that I think cross
the line and are bad for users, I think that it's worth noting that these
judgments are highly contextual. 

4 years ago, it was every self-respecting web developer's duty to upgrade his
or her friends and family from Netscape 4 to something that might actually have
implemented something like a published W3C spec. At the time that was IE 6. But
how fickle our allegiances! Today the suggestion that someone should use IE and
not Firefox is more likely to earn you a dirty look and a kick to the groin
than a knowingly approving nod.

So what gives? Were we wrong in 2000? No. It's just that the larger goals of
usability, portability, accessibility, and security are better met with this
newer alternative than with our former choice. 

I'd like to suggest that the same thing is true of web standards. While browser
churn is a slow, grinding process that eventually leaves us in a better place
as the market does that thing that it does, web standards are similarly in
flux. More importantly though, the actual parts of the specs that are
"available" to developers change not as a function of when (or even if) things
are ratified by the W3C or ECMA, but as a function of what browsers actually
ship. 

While it's nice that we have some set of documents that describe what it is
that the browsers should be implementing, I think it's important that we as
implementers take the position that if every browser supports something, then
by god it *is* a standard. It's time that we as a community finally sucked it
up and realized that things are going to continue to change underneath us and
that the best we can do is to squarely fix the end goals of usability,
portability, accessibility, and security in our minds and work toward those.
Strict adherence to the musings of a working group at the detriment of those
goals should no more be tolerated than should flaunting them for the sake of
making people's lives worse. If can't at least learn this much from the story
of the XMLHTTP object then we deserve whatever infighting we may self-inflict.

But back to Ajax...

I think that if we can say anything about Ajax and where it points, it's a
signpost on the road to improved interface responsiveness on a platform that
doesn't require a tax or have a single vendor in control. It's furthering that
progress that we're building Dojo around, and there are a couple of core areas
that I feel are fundamental to making it happen.

While other people are also working on addressing some of them, Dojo's
philosophy is to build powerful abstractions that either smooth over the places
where browsers differ or provide pluggable abstractions that allow for native
implementations to fill in for things that are today built in script. Dojo can
help you take advantage of newer capabilities sooner and without worry about
future-proofness.

The first building block we're tackling is cross-domain Ajax. There's a growing
number of web services available on the public network that provide access to
all manner of interesting data that may not be useful on its own, but when
introduced into the context of your application can make a huge difference in
what your users can know about a situation or problem. 

Today, exposing these services to Ajax requires writing a proxy service, but
providers of some of the most interesting of these services, notably Yahoo, are
starting to make the data from their services available directly to browsers
using a script tag insertion method that the newly relesed version 0.3 of Dojo
provides a unified API for.

Imagine an application that's served from your domain, saves state to your
server, but relies on Yahoo, Amazon, or Google for most of the heavy
lifting...all without you proxying the traffic. This is mashup-plus-plus
territory, and we can start building it today. Eliminating then need to proxy
requests will allow services to scale up much more quickly and also enable a
whole series of applications that use external services to provide discussion,
collaborative features, or extra data about something already in an app. It's
the next logical step toward truly making the browser the application platform.

Building on this, we've extended Dojo's package system with the ability to load
packages across domains without a proxy. For developers with large-scale
deployment scenarios or folks who are looking to host their highly-cacheable
packages in Content Distribution Networks, this allows for pain-free
transitions between development and deployment and lets you edge-cache your
shared tools for use across properties and domains.

Next, we've developed a high-performance local persistent storage interface,
with an initial implementation based on Flash, that allows you to save
information about the state of your application or cache large chunks of data
that might otherwise be infeasible to send every time the application loads.

Unlike Macromedia's Flex Ajax Bridge, our implementation doesn't require Flex,
features high-speed data transfer even on the broken Flash 8 APIs,
transparently handles plug-in upgrading, and builds without proprietary tools.

As is the Dojo way, we've defined a generic interface that will allow other
implementations to plug into the storage system when the browsers provide the
capability natively. The What Working Group is standardizing such an API,
Mozilla has committed to implementing it, and with Dojo you can start writing
to a stable, portable baseline while we wait out the browser implementation and
upgrade cycles.

Lastly, together with a Perl project, we're working on a Comet client that will
help to standardize packet formats and wire protocols for low-latency data
transmission from servers to browsers. This work is going to help enable more
folks to build the kinds of instantaneous collaboration and discussion
behaviors that systems like Meebo, Renkoo and GMail have started to make
common. Without a system like this, Ajax solves one half of the interaction
latency problem. Since Ajax is user driven and since the context displayed in
the app may change as a result of actions by other users, the context in a
long-lived Ajax page may become very stale. Comet combats this by allowing
servers to distribute events to interested clients as soon as they happen,
without polling.

These are a couple of examples of things that we see as being on the cusp of
being "available" and we're using Dojo as a platform for attempting to drive
their adoption well before they might otherwise arive. If the Open Web is to
remain viable, we need to keep building headroom into the platform so that
application authors can do better by their users tomorrow than they did
yesterday.

Ajax was evolution, not revolution, and whatever these new Open Web
technologies are called, it will also evolutionary.

Dojo will keep evolving with them to reduce the lag between "implemented" and
"available".

Thank you.