AJAX Demystified Part 1 of 3

What is AJAX?

If you think that AJAX is a cleaning product then you your reading the wrong article and you should stop immediately. However if the people you talk to on a regular basis keep using words like AJAX and web 2.0, then this article is for you.

The acronym AJAX stands for Asynchronous JavaScript And (+) XML.

OK…. But what does AJAX really mean?

AJAX has been described as way to build rich/dynamic Internet applications that are interactive and responsive. Rich and dynamic Web Sites and Internet Applications typically have one thing in common – they are heavy. Heavy in the sense that that entire rich content means larger downloads and slower performance for the end user. So, how does AJAX help to make sites more responsive? One of the primary ways is to render the page once and then update sections of the page without having to reload the entire page again. So now, with AJAX, every time a content element changes, we no longer have to reload the entire page, just that particular piece of content.

Where did the catch-phrase “AJAX” come from?

Back in early 2005, Jesse James Garrett came up with acronym AJAX. Looking back this is not the best acronym for the technology described but the Internet community adopted it and the rest is history. The irony of it all is Jesse did not mean for it be an acronym.

Do I have to know or use JavaScript to develop an AJAX App?

The short answer is no. There are many AJAX enabled languages/frameworks that require the developer to use little or no JavaScript. A few popular frameworks include Ruby on Rails, Microsoft’s ASP.NET AJAX 1.0, Sun’s Java and Adobe Flash. Each requires little or no knowledge of JavaScript to build an AJAX enabled web app. Most of the frameworks listed above create the JavaScript for you.

Nevertheless, if you don’t want to use a specific framework on the back end, then doing your own AJAX implementation gives you the greatest flexibility. The other possibility is to use a JavaScript framework that supports AJAX, one of the most popular being Prototype JS. In fact Ruby on Rails has integrated Prototype directly into its own framework. In our experience, using the Prototype framework still gives you the greatest flexibility without locking you to specific back end framework.

Do I have to use XML?

The XML part of AJAX acronym can be the most confusing part. At times you will use XML to send and receive data between the browser and the server, however most of the time you’ll probably be receiving HTML content and using the DOM (document object model) to update a specific section of the page. Don’t feel guilty if you’re not using XML, it’s not a requirement. This is another reason why AJAX is probably not the best name to describe the technology. You could create an entire AJAX enabled site and NEVER use XML!

Before AJAX we had the Postback! (Rinse and repeat)

Before AJAX enabled web applications, the process was simple:

A User’s browser makes a request to the Website.

The server receives the request.

The server processes the request and resends back the entire page.

A User’s browser receives the request and renders the HTML.

User enters some data, clicks a button or hyperlink and then sends the request back to the server.

Repeat the process.

However, there are a couple of problems with this approach:

The server is doing all the work. The server is sending the entire HTML of the page each time there is a request for the web page.

The amount of data sent back can be large and when it’s been sent back several times it compounds the problem.

The browser has to completely render the page each time it receives the content from the server.

The application does not feel responsive. You’re waiting for the server to give an update.

The site is not very interactive. If you don’t do anything with the page you’re not getting any feedback from the server.

When the first browser was created for rendering HTML, it was just that, a browser. New innovations were introduced for modern browsers (Fire Fox, Internet explorer 6+, Safari, and Opera) such as client side scripting languages (JavaScript, VBScript) and the availability of the Document Object Model (DOM). The average computer today and its browser are extremely powerful and are capable of doing more of the work that was traditionally done on the server side.

Finally, the number of potential people browsing your web application has increased and will continue to grow causing more work for your server(s). Reducing the workload by sending less content for each request, your web application will feel more responsive and will be capable of handling more users requesting content.

Let JavaScript and the browser do the talking!

Now let’s talk about the AJAX way. Instead of using the Form Tag to do the send requests to the server, we are going to use JavaScript to make the request. When the server sends back the information we use JavaScript to dynamically update the page without having to render the entire page all over again.

Another advantage is that the request is being made asynchronously (Hence the Asynchronous in AJAX).The user is still able to interact with the web application while the request is being made to the server. When the response from the server is returned to the browser, a call is made to a JavaScript function that handles the response. This is called a callback function. The advantage is that you’re not waiting around for updates to occur; this is what makes AJAX enabled web applications so powerful!

This concludes part 1 of 3 on Ajax Demystified.

Check out Part 2 where we go into more detail on how to actually write a simple AJAX app.

3 comments ↓

#1 Don Hansen on 04.23.08 at 10:35 pm

Cool article. I have actually been using JQuery to do a lot of my AJAX code, and it is amazingly easy. I just add a line of code to my main page that goes out and gets the content I want to update with.

I just wish I’d have found it much sooner, as many of m apps I built in the past are bloated with postbacks.

My most current project, I have one page that is built completely on the fly based on user input and it I build each portion using the AJAX. In the past it would have been postback after postback, would hav had the screen flicker for each one, and the performance would have not been as rich.

#2 AJAX Demystified Part 2 of 3 — Thought blog on 04.24.08 at 9:23 am

[...] ← AJAX Demystified Part 1 of 3 [...]

#3 AJAX Demystified Part 3 of 3 — Thought blog on 04.30.08 at 10:12 am

[...] 28th, 2008 | PHP, ajax, javascript, ruby Part 1 of AJAX Demystified we discussed what is AJAX and gave a high level overview of how it all [...]

Leave a Comment