Why Microsoft and Google are Cleaning Up With AJAX

OSS_ilation writes "Google uses it, and Microsoft is pursuing it, so there's a lot of hype and hubbub surrounding AJAX (Asynchronous JavaScript and XML). AJAX brings together some hot properties, JavaScript, HTML/DHTML and HTML, according to Julie Hanna Farris, founder of Scalix, a Linux-based, e-mail systems vendor. Scalix is using AJAX in Scalix Web Access (SWA), a Web-delivered, e-mail application. AJAX enables advanced features like drag 'n drop, dropdown menus and faster performance capabilities, which are now making their way into Web applications, she said. These kinds of capabilities represent a significant leap in the advancement of Web apps."

Comments

Funny thing is...

[man_of_mr_e]

Microsoft basically invented AJAX, yet they're the ones behind the curve.

Microsoft invented the XmlHttpRequest functionality, AND they've been using AJAX (before that's what it was called) in Outlook Web Access (OWA) for years. Nobody else in the company seemed to have caught on to it though.

What my dog hears

[hillg3]

Anyone remember the old Gary Larson cartoon? Man talking to dog, bubble above dogs head captioned, "what dogs hear."

"blah blah blah AJAX, blah blah blahblah AJAX!!1!. blahblahblah Google blah AJAX, blah Microsoft sux."

A better web page scripting language?

[ThinkingInBinary]

I'm not sure if your comment was intended as a pointed jab at the buzzword status of AJAX or a serious suggestion that JavaScript is crappy, but I'm assuming the second.

There are some things about JavaScript that are really annoying. First, the object orientation seems very odd. It is well-rooted in the language, but it is quite annoying not to have real object namespaces (yes, you can use closures, but they're annoying and kludgy), real constructors, and that sort of stuff. It's almost as bad as Perl's hash + namespace = object idea, and worse in some ways.

What I'd like, I guess, is a language that is very similar to JavaScript, but has a real object-oriented system and better support for things like loading code dynamically. It's clear that JavaScript or some future variant of it is finally being used the right way--to make pages dynamic instead of just annoying--but right now it's very cumbersome. Loading Gmail, for example, is quite slow, because it (IIRC) downloads a huge chunk of code at the beginning. Perhaps someone (maybe me) could write a wrapper system in JavaScript that uses XmlHttpRequest to load JavaScript code on demand. But some sort of modular functionality ought to be officially added to JavaScript, before it's too late and we end up with the next "___ Wars"... this time it will be the fight between JavaScript frameworks.

Incoming data

[n0dalus]

I think that if AJAX picks up and starts to be used everywhere, we should standardize a system so that optionaly, a web browser can inform the server that it has the option to connect to it using an open port on that system. It would really help things if the browser didn't need to connect to the server every few minutes to check for new data. That way, instead of my browser connecting to Gmail's servers every 60 seconds to check for new mail, Gmail's servers can connect to my browser and tell me only when I have new email. This saves processing and bandwidth and increases usability.
This turns AJAX into more of an actual internet protocol, and I think it would really improve things.

Re:Incoming data

[KiloByte]

1. The good ancient way.

Try this:
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
$|=1;
(print '.'),sleep 1 while 1;

2. With XMLHttpRequest:

var req = new XMLHttpRequest();
req.multipart=1; ....

and the server-side part uses content-type: multipart/x-mixed-replace

AJAX: Almost Just like an Application!

[MobyDisk]

AJAX is great. It means that web deployed applications are now almost as good as the regular applications we've been using for over 10 years! Just imagine: We can enhance Javascript to support more OO features and reflection and add JIT and it will become just like Java! Yaaay! Then we can add support for stronger typing and compiling to native code, and then it will be just like C! Yaay!

It is funny to watch technology reinvent itself in fast-forward.

I work for a company that did AJAX long before it was called AJAX. And now that it is the next hot thing they are moving away from it. Why? Because they already learned the lesson that everyone else is about to figure out: AJAX is a b*stard to code and maintain. It is easier to write a client-server application in a traditional language and web deploy it than to write this crazy JavaScript + XML + HTML + DHTML + CSS stuff.

Java and .NET natively support this. For other languages there are plenty of frameworks that will add that capability.

Re:Platform independent?

[dmeranda]

It's almost platform independent. The main problem which primarily afflicts Microsoft's use of AJAX, such as in Outlook Web, is the way that the "A" in AJAX is "started".

Basically to initiate an HTTP asynchronous request, the Javascript code must create a special object which encapsulates the request and communication. Althought the interface and use of this object is for the most part standard, the way in which it is initially created is not.

• Standard (everybody but IE): req = new XMLHttpRequest();
• MS-IE (new): req = new ActiveXObject("Msxml2.XMLHTTP");
• MS-IE (old): req = new ActiveXObject("Microsoft.XMLHTTP");

So if you want a platform independent AJAX app, you pretty much need a bit of code which does things the Microsoft way when the standard ways don't work. Like:

try {
req = new XMLHttpRequest(); /* The pseudo-standard way */
} catch(e) {
try {
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
req = false;
} } }

Now, Microsoft-written applications which use AJAX only try the MS ActiveX methods, and not the standard XMLHttpRequest() function. Thus, although most of the application could have worked in any browser, this simple omission by Microsoft insures it only works under IE (and locks you into their technology).

It should also be noted that AJAX is a methodology and not a strictly defined API. For instance most AJAX apps rely heavily on the DOM API, which Microsoft mostly but not entirely adheres to. So there's lots of things that can cause platform independence problems if not coded carefully.

Re:AJAX = Suckjax

[freeweed]

I keep seeing comments to the effect of "Java could do this!", and I'm going to pick on yours :)

See, Java *could* do this. Sure. I'll give you that. In fact, most people until recently HAD a JVM in their browser. Java applets should have taken over the world.

Why didn't they? Why is AJAX getting all the press Java should have gotten?

Me, I simply look at 2 things: gmail, and Google Maps. They both work, work well, and work better than anything else. Apparently millions of people agree with me, just look at the buzz around them. Are we all brainwashed by Google? Could these have been done as a Java applet? Maybe.

The fact is, they WEREN'T. Or if they were, no one used them. The way I see it, AJAX is the end all and be all (for now) because it WORKS. Maybe Java is just too slow (and here come a dozen posts claiming it's not). Maybe the wait time to load a JVM into memory, plus download an applet is too long. I don't know why Java hasn't been used, but it's not like no one's thought of it before.

I get the hype, myself. It means that I can sit at virtually any computer, type a URL, and BAM! Instant application. I've yet to see another technology that works this well.

Re:real reason why

[misleb]

It is bullshit. AJAX does NOT give one the ability to deliver desktop quality applications through the web. Not even close. Sorry. At best, AJAX spices up traditional web applications. But it is still using HTML/CSS for the UI. The HTML/CSS document model simply doesn't work well for desktop quality applications.

Saying that AJAX will allow one to deliver desktop quality applications is like saying central heating will turn a mobile home into a mansion.

-matthew

Re:Ditch Javascript

[JesseMcDonald]

I agree that both models are necessary. You wouldn't want to lay out text with a box model, but you wouldn't typically want to lay out a form or list with a freeform layout, either. The element was a decent compromise, for a while, but its limitations are many, and it confuses programs that expect tables be used for data rather than layout. CSS is the recommended replacement, but omits the most useful part of the element, arranging rows and columns of arbitrary elements, while failing to add the metainformation that would allow screen-readers and the like to quickly find the content of the page.

You say that we're "trying to force documents to be applications", and I agree. However, with HTML we're also trying to force applications to become documents. We need access to both layout models, because the Web contains both documents and applications. XUL provides this. For example, the XUL menus in the FireFox "chrome" are freeform, and the main part of the box layout is a container for freeform HTML, while the rest of the chrome follows a box model.

Even "document" pages usually contain some "application" elements; navigation buttons, or a search box, for example. The page should be treated as an application containing content, and not forced to hold both the framework and the content in one file, with the same layout model.