What is AJAX? And why we (don't) use AJAX...

Monday, August 8, 2005 3:45:00 PM

I read the blog from Wallace What is AJAX? Yes, what is AJAX and why do we want to use AJAX?

  1. We have to use AJAX because everyone is talking about it!
  2. We have to use AJAX because big companies (Google, Amazo, Microsoft) are using AJAX!
  3. We have to use AJAX because it is faster than have a postback for each call!
  4. We have to use AJAX because...

BUT: Are we using AJAX? Have a look on the name of AJAX: Asynchronous JavaScript and XML. If you ever used my Ajax.NET library you are not using AJAX!! I started the Ajax.NET library after I have read the article A New Approach to Web Applications (Jesse James Garrett, adaptive path). Before the library was called CSharpWrapper. Changing the name to Ajax.NET and adding more features was the correct decision at the right time. Inside it is the same, I'm using the XmlHttpRequest to transfer data to and from the server without a postback (and a complete page reload).

If you have a look inside the Ajax.NET library you can see that I'm not using XML to transfer the data to or from the server. I am using the JSON syntax because it is supported by I think all modern browsers including Pocket IE (Windows Mobile). It is very simple and you can get a real JavaScript object using one command: eval.

In the future we will use the XmlHttpRequest to post and get data from the server using the HTTP protocol, synchronous or asynchronous. We will serialize the data (objects) using strings (JSON), XML or maybe binary data. On the client we are using JavaScript to change parts of the web page using DHTML/DOM.

The conclusion is: AJAX is still a cool name! Now, that we have the acceptance of developers and web designers we should concentrate us on the correct usage of the XmlHttpRequest object. I still get strange questions concerning the Ajax.NET library because of missing understanding how HTTP, postbacks and browsers are working.

12 Comments

  • Erv Walter said

    I wouldn't worry about AJAX.NET not techincally being AJAX. Heck, Google Suggest (one of the common examples given for use of AJAX) is not using XML either... Seems like they are just returning Javascript to be evaluated as well...

  • Stuart Ballard said

    It would be fine if we just retroactively pretend that AJAX stands for "Asynchronous Javascript and XmlHttpRequest"...

    JSON is an excellent choice, IMHO, for the format to actually send back through the XmlHttpRequest. The reference to Xml in the name of XmlHttpRequest is actually unfortunate IMHO; it would be nicer if the concepts of an HTTP request and an XML parser were cleanly separated in the browser's API.

    The only time I've used AJAX, I just sent a simple string - no structured data at all. Worked fine for my limited needs...

  • Dan Barthel said

    AFIK, no one developing a serious ajax package uses XML, and for good reasons 1) bulky 2) need XML parser on browser which raises compatibility issues. Stick with JSON, and maybe look at the rest of the stuff in JSON-RPC.

    Dan

    Cool name, though.

  • Dave Tigweld said

    Much like many other people I've had my own "AJAX" library, which has been in use since 2001. It could be classified as ajax by some, but maybe not by a purest.

    I'm kinda sick about reading all this hub bubaloo about AJAX. Its not new people.
    I saw people using Java to communicate to the server since its release. Microsoft gave us the xmlhttp object and live scripting back in the 90's.

    In my library,
    - I don't use XmlHttpRequest(Some machines running IE 5 back in the day, had problems with this object so I vowed never again to rely on it).
    - I send xml to the server
    - I return Javascript

    You can call it AJAX if you want or not I don't care.

  • Michael Schwarz said

    @Dan: Yes, the first version was using XML and I was not happy because of the missing XML parser on some browsers. The JSON syntax is the same for all browsers, no isIE or isMozilla code. I hope that Microsoft will add a native XmlHttpRequest for Internet Explorer 7.

    CIAO
    Michael

  • Michael Schwarz said

    @Dave: Exactly, this is what I think, too! Like you others are using similar ways to communicate with the server without the need of any postback years ago. Since ASP.NET was released a lot of non-developers could write faster code, but with the postback the forgot that events are not possible with the HTTP protocol. I hope that Atlas will enhance ASP.NET with this missing in-the-box feature.

    CIAO
    Michael

  • Ryan said

    It's been nearly a week since you stated that SediSys took over the source, and the only thing that "chris" from sedisys has said is that the source would be up that day or the next (5th or 6th).

    Have you heard anything new?

  • Ron Buckton said

    I tend to prefer the ASP.NET 2.0 approach to client-side scripting. I build a lot of sites today on .net 1.1 and .net 2.0 using client callback functionality. The basic idea is to compose server controls that work with or without the client script functionality. The client-side activities can be reproduced through postbacks and vice versa. The result is a relatively clean design (two paths end up at the same processing logic) which can hit up and downlevel clients. The real fun is getting cross-communication between client-aware server controls.

    AJAX is just a buzzword for a long-standing technology. Remember the old MSDN TOC article way back when? MS was buzzing about using Microsoft.XMLDOM and doing XSL transformations against data pulled at runtime from the client. This translated into a lot of people (myself included) using JS, XMLDOM, and XML-RPC style code in ASP. Back in the ASP days I also went the route of JSON and eval() style calls. I used to have an old ActiveX component in VB (not .NET :) that I need to someday find that exposed portions of a server-side COM object using XML-RPC in classic ASP. This was probably about 6 years ago. Funny how things seem to always come full circle.

  • Rimu said

    who cares if you use XML under the hood or not. what matters is the function that your library provides, and it's name should reflect that.

    the function that your library provides is the same as other ajax implimentations, so call it ajax! :)

  • Harry said

    Ok, we use Ajax (or some combination of this) because it *feels* faster to the user (although it may not be).

    Cross-browser compatibility? Hardly. There is no such thing, and IE is becoming more and more marginalized. I refuse to use code that only works on IE - having everything do postbacks instead of client code just because the client isn't IE is rediculous.

    Oh, and why come up with the term "downlevel browser", when "not IE" works just as good?

Comments have been disabled for this content.