Ajax Is the Buzz of Silicon Valley

Carl Bialik from the WSJ writes "Ajax, or 'Asynchronous JavaScript and XML,' is allowing webpages to update as quickly as desktop software, powering applications like Google Maps and attracting money from Silicon Valley investors, including for a collaboration-software company called Zimbra. The Wall Street Journal reports: 'Zimbra's chief executive, Satish Dhamaraj, says that when he started his company in December 2003, "I really thought that Ajax was just a bathroom cleaner." Now his San Mateo, Calif., business has amassed $16 million in funding from venture-capital firms including Accel Partners, Redpoint Ventures and Benchmark Capital, the firm that famously funded eBay Inc. Peter Fenton, an Accel partner, says Ajax "has the chance to change the face of how we look at Web applications" and could boost technology spending by corporations, because Ajax is also being used to develop software for big companies, not just for consumers.'"

Comments

So, nitpicking...

[Dirtside]

Shouldn't it be AJAX, not Ajax? Ajax is the Greek warrior.

Re:So, nitpicking...

[kritikal]

I can't remember the original source that mentioned something like this, but the author of the piece was arguing that to refer to it as "AJAX" you are only referring to things that involved Asynchronous Javascript and XML. With most of the tasks that I've found a use for "AJAX" I've never used XML. Rather, we should just be referring to the general sense of using either XMLHttpRequest/Iframes as "Ajax" to keep things simple for consumers.

Re:So, nitpicking...

[LDoggg_]

I've never used XML. Rather, we should just be referring to the general sense of using either XMLHttpRequest/Iframes as "Ajax" to keep things simple for consumers.

IFrames are not required for AJAX.

All you need to do is have an xmlhttprequest object called by whatever event you like, it can then take the response and then somehow (usally div tag) change the contents of a web page. That's it.
The use of Iframes is 100% optional.

Re:So, nitpicking...

[LDoggg_]

The phrase "Dynamic HTML" pretty much sums up what AJAX is, which is nothing more than using Javascript to make server requests and modify the DOM. It's so annoying that for some reason, the press is acting like this is a new technology.

The interesting part is the first "A" in AJAX, its asynchronus meaning it doesn't require a comlete page refresh to retrieve data not already contained in a web page.
This isn't new, its been around since IE 5.0. What's new is that browsers other than IE support xmlhttprequest object now. This has enabled companies like google to use the technology, thus creating a buzz.

Re:So, nitpicking...

[kin_korn_karn]

and no system-killing JVM startup. That's what I hated about applets.

Re:So, nitpicking...

[ergo98]

The use of Iframes is 100% optional.

? The parent poster was giving those two options as alternatives, not as a combination. e.g. if you can't use xmlhttprequest, then you use a hidden iframe to do the background transfers.

Re:So, nitpicking...

[Taladar]

If it works in all major browsers why does my Opera on 64 Bit Gentoo Linux display nothing but a window with "Loading..." without ever loading anything on GMail? That is the one thing I absolutely hate about AJAX, it is pushed today by the very people crying for more standards and compatibility in the Browser market yesterday and just because it happens to work in Firefox AND IE the fact that it doesn't work with 99% of all other HTTP clients is no longer a problem.

Re:So, nitpicking...

[LDoggg_]

When I first started using it I tried out several different helper libraries, but found that it all basically just came down to something really easy like this (with better formatting, of course):

var xmlHttpRequest;
function xmlRequest(url)
{
if (window.XMLHttpRequest) {
xmlHttpRequest = new XMLHttpRequest(); } else {
xmlHttpRequest = new ActiveXObject("Microsoft.XMLHTTP");
}
if (xmlHttpRequest) {
xmlHttpRequest.onreadystatechange = _processXmlResponse;
xmlHttpRequest.open("GET", url, true);
if (window.XMLHttpRequest) {
xmlHttpRequest.send(null);
} else {
xmlHttpRequest.send();
}
}
}

Do the work with the results something like this:

function _processXmlResponse()
{
if (xmlHttpRequest.readyState == 4) {
if (xmlHttpRequest.status == 200) {
//do stuff with xmlHttpRequest.responseXML.documentElement
} else {
// do error handling
}
}
}


YMMV but this generally worked on my target browsers.

BTW, nice site.
One suggestion when you hit the (+) to open an item it should turn into a (-) to close it from the same place.

Desktop.com

[_flan]

Desktop.com had this stuff in 1999, but unfortunately the browsers of the day (IE4 and Netscape 4) weren't really capable of staying up long enough to make it worthwhile. There was even a company that had a nice little web-based spreahsheet app.

Still, I haven't seen a good, platform-independant, integrated sever- and client-side solution yet. Back at Desktop in was *all* client side except the actual persistence of objects so it wasn't really an issue.

Ah, well.

Re:Clean-sweeps the competition

[mooingyak]

Well this sounds like fun...

Hows about

Decoupled Agile Web Networking

Wow that doesn't make any sense.

AJAX is creative glue

[joelsanda]

Seriously you build upon the failures that DHTML, HTML, Javascript, XML, XMLHTTRequest and you form a system which requires at least a 1 ghz processor just run a very simple GUI.

AJAX-enabled applications like Google Maps and GMail run fine on my G3 iBook with Safari and OS X 10.4. I don't think they necessarily have to have additional processor requirements on the client side.

Saying DHTML, HTML, Javascript, XML, and XMLHTTRequest are all failures is a little extreme. Saying each fails at being everything is 100% correct and 200% redundant - nothing is everything. I applaud the use of XML and Javascript to place more processing on the client side. It's not without its problems, but then nothing is everything.

This is also a good example of how bad Java and Sun has failed. If Sun would've opened up Java, let people distribute it, as well as from day 1 enabled easy RMI over HTTP we wouldn't be up to our necks in a horrible mixture of presentation logic and business logic.

I agree with this - this was Sun's sweetspot about 10 years ago, wasn't it? Client's connecting to applications so our experience was built upon thin clients instead of desktop applications.

So here we are, requiring gargantuan browser which are brought to a halt with this AJAX technology when we had many other technologies which did so much better but failed for various other reasons.

Again - this is just not true, at least in my experience. If my 800 mhz iBook with OS 10.4 and Safari can run Gmail as fast as Mail.app then I'm sold on the usability of quality engineered AJAX-enabled applications.

except that

[circletimessquare]

no one cares about what you care about

i'm being serious here: 99.9999% of web users don't really care if your screen scraper program is harder to write now

you are speaking from an idealistic point of view that doesn't really drive the web

the web is all about, and i mean all about as in the first issue and last issue under consideration, end user experience

everything else is trivial

i'm not in any way joking or trying to be flippant

if web users go "cool, you can drag the google map around, that's so much easier to use than mapquest" then every single thing you just said goes right out the window

end users rule with an iron fist for all development efforts, period, end of story

never forget that

realism trumps idealism

Re:Ajax and Productivity

[Anonymous Struct]

I'll second that. Over the years I've had to write a handful of small web tools to get things done around the office, and my biggest lament was always that data entry really and truly sucks with forms that have to submit and reload. Then I read about this ajax stuff a while back and retooled a few interfaces to use it instead. Now, my whites are whiter and my colors are brighter, I get better gas milage, my lawn is thicker and greener, and my golf game is better than ever.

Actually, none of that other stuff happened, but the data entry interfaces are much, much more usable than they used to be. Three cheers for new stuff!

Re:AJAX is just an acculmulation of failures

[claytongulick]

I couldn't agree more. People frequently lose perspective of the fact that AJAX is just one option, and IMHO not even close to the best.

I've been doing all my recent development in OpenLaszlo and honestly, I have never seen any UI technology that can compare. And I'm doing more than just playing with it, I'm developing a full blown enterprise app with it at work.

For those who are looking for really impressive web based UI technology, I can't recommend it enough.

Here are some of the strong points:
-open source
-tag/xml based language - very declarative, instead of tons of scripting, you can just define "states" of your views and bind those states to an attribute
-Object orientation that *really* works and is helpful - not like AS2 in flash

-"Serverless deployment" - this is one of the coolest things - your entire app can (optionally) compile to a single SWF that can be redistributed by your method of choice. I should point out that you can also run it in "server" mode where you can edit the .lzx file on the web server and it will automatically recompile, just like JSP or ASP.NET
-Animation. Every attribute is animatable... via script or declarative animators. It is hard to describe just how cool this is until you see it in action - to make a view fade out, for example, I can just do this:

<animator attribute="opacity" to="0" duration="500" />
or
this.animate("opacity",0,500,false);

either way gets you a nice fade out over 500ms. It couldn't be easier.

Anyway, sorry to drone on so long, but this is by far the most impressive UI tech I've seen. I know it has been mentioned on slashdot before, but I'm constantly surprised at how few people seem to know about it.

-Clay

Re:AJAX is just an acculmulation of failures

[sterno]

Java failed on the desktop because:

1) You had two different browsers each with their own JVM plus a third JVM that you could download and they all behaved slightly inconsistently.

2) The Java applications were painfully slow

Now, go to google maps and tell me that it's slow. It doesn't matter what the software uses, it matters what you perceive. If you perceive waiting, sluggishness, etc, then it's a problem. This is common sense programming. You target a platform and you develop software that works well on that platform.