A simple feedback of AJAX for beginners

Website script holds large importance as far as popularity and usage convenience are concerned. As an innovative web language AJAX may not be very popular as it has come quite recently as compared with other web languages which have been around for last 10 years or more. For beginners a quick feedback of AJAX can be helpful.

AJAX is really faster in its application as it does not need connection to server every time you ask for the information. Call back process for required information from users is capable enough to avoid sluggishness of page view. Data updation has been made quite simple and there is no need to review the entire contents. The system can select the bits to update. AJAX uses those scripts which are normally supported by all major browsers.

If you are planning to develop a new website, you can try AJAX. Online tutorials are available to get basic start up guidelines also.

Life Cycle of AJAX

A Typical Life Cycle or Process of AJAX

Life cycle of AJAX is more similar to a traditional GUI than a traditional web application. It has DOM objects who acts like GUI widgets. The used script has capacity to register even listeners on DOM objects and respond accordingly after manipulating DOM.

There is an important part of the event-processing cycle in server is evoked sometimes. As the server calls are asynchronous, the even listening and event responding are done separately.

The normal AJAX life cycle consists of following stages:

1. The webpage is visited by internet users simply by clicking the targetted link or searching an URL. Thereafter the page gets initialised and loaded. In order to handle the user input callbacks are present in the system which acts after this.
2. When a key is pressed it’s called an event which is a query or click in common words. On such events browser sends the information request to the server which in turn responds to give back required information as bites.
3. The response of the server is translated through callback process to made viewable to the user.
4. The callback function then updates the DOM objects and javascript variables if present.
5. Generally the process of requesting information and giving callbacks are free to server to increase convenience and speed.
6. Some AJAX applications are short term and terminated once the request is completed.

AJAX: Introduction and Advantage

Basics of AJAX:

AJAX is defined or termed as Asynchronous Javascript and XML. It’s a new avtar of modern day website creation. AJAX is one of the programming techniques which has primarily made popular after 2005 by Google. No doubt about it that AJAX has set innovative and new standads of programming. AJAX has enabled webmasters create better, faster and more user-friendly web applications with its base of Javascript and HTTP.

AJAX is based on 4 web standards which are well defined and supported by all major browsers.

1. JavaScript
2. XML
3. HTML
4. CSS

Basic Advantage of AJAX

Faster Updation: If you want to update the data base of your web AJAX provides an unique feature to reduce consumption of time. Unlike other web languages where you need to update the entire data base every time you need to update the contents, however with AJAX you need to spend time only on updation of the contents which actually requires to be done so. AJAX selects the contents from the web which needs updation giving eage to the process.

Faster Response: AJAX enables faster responses to the inputs even if the changes are not done on server. The unique advantage of AJAX is its ability to reload the individual pages separately giving a user friendly benefit and users may perceive the site functioning faster.

Faster Connection: With AJAX it’s not required to connect the webpage with server every time. Some times it saves the interaction between them to increase functionality and speed. It allows webpage to request for smaller bits of information rather than asking for the entire page to load again and again which increases speed as well. AJAX is a technology related to browser which is independent of web server.

RSS updates via your instant messenger

I thought this new web application immedi.at might be of interest to AJAX Blog readers. It only uses AJAX sparingly but it is written using Rails and offers a unique capability that may be useful to some: the ability to recieve update notices in any instant messaging client when an RSS feed of interest changes.

This is kind of cool for certain things because you don’t have to actively check to see if stuff has been added to certain feeds, they come to you. Like, I use it to monitor comment threads on some blogs as they develop and to get updates when I have new gmail messages.

Simulating Latency with Greasemonkey

Julien Couvreur has another approach to simulating network latency in AJAX apps - XmlHttpRequest - Add Latency. Certainly a neat solution in terms of lines of code Some random thoughts, perhaps to give Julien ideas.

When considering AJAX Proxy had half thought of Greasemonkey although figured an HTTP proxy is a more “honest” solution. Re-thinking, will probably work just as well with Greasemonkey.

Some specific things I wanted to be able to simulate with AJAX Proxy, with reference to Julien’s approach;

• Latency swings both ways. A delay could occur in the direction from client to server, sending a request. A delay could also occur from server to client, as the response is delivered. OK - that’s not exactly how the HTTP protocol works but from an application point of view, it makes a useful simplification.
  For example consider an AJAX chat application - there might be an operation on the server called “save message” which stores a single chat message sent in a request by a client. The response from the server to this operation is simply an “OK” or “Failed”. So what’s interesting is really any delay in the client to server direction. If the latency is varying over time (which it might), it could be possible that “Message A” and “Message B”, sent by the client, are received in order “Message B” then “Message A” by the server. The server needs to check the messages are stored in the right sequence (which implies the client is providing some kind of sequence information)
  Meanwhile another server operation, “get new messages”, is polled by the client to obtain new messages after a certain time or sequence ID - varying delay in either the server to client direction or vice versa causes new messages to be received by the client in the wrong order; the client also needs to check the order of what it receives.
  At the moment Julien’s solution is only delaying messages in the client to server direction - the delay he uses is inserted before the request is actually sent. Think it also needs to be possible to have a delay inserted after the response was received from the server but before the corresponding callback function is executed ( that’s going to dramtically increase the lines of code required though).
• Latency may vary over time. Julien uses a consistent delay, which will highlight painful end-user experiences but as the above point illustrates, it’s more subtle than that. On a typical network would get “spikes” and similar that mean things like for half a second response times are really bad but then recover. Depending on what you’re doing with AJAX this may mean you need to implementing “queueing” or sequencing - the Starbucks factor.
• Latency is not predictable. Basically the same point as above but would be nice if Julien’s solution supported “randomness” as another mode of testing.
• Sometimes it just fails. And a request might fail to get to the server or a response might fail to get back to the client - complete network failure somewhere down the line. From what I’ve seen with AJAX Proxy, when completely dropping requests and responses, the current browser XMLHttpRequest implementations do little, if anything, to report this to the caller (or callback). And from testing a few online AJAX demo’s (I’m avoiding naming names here but I’m sometimes sorely tempted) this will mean data loss for some apps.

Think it should be possible to simulate all of those conditions with Greasemonkey, although it’s a fair amount of work. Wish Julien good luck with it.

At some point will give AJAX Proxy a decent CLI startup interface (rather than having to hack the code) and package it with py2exe but right now, no time.

Another angle someone should look at is fiddler, which is basically AJAX Proxy but a lot better (Windows only though). Check out this forum post - should be possible to implement all of the above with JScript and fiddler.

Question: Is all this really a problem? We all care about accessibility, right? Well this is accessibility in the literal sense. You need to leave localhost realise this is a real problem - take a holiday to South Africa then try accessing your AJAX app over in the States. Failing that, make a friend of a South African - you may learn some new swear words.

AJAX Proxy 0.2

Version 0.2 of of AJAX Proxy is out - available here. This one actually passes on the POST body (duh).

The basic instructions on setting up Python are the same, as described earlier.

Configuration of the script has now changed - at the end of the script you would modify;

[code lang="python"]
if name == ‘main’:
REAL_TIMEOUT = 10 # Timeout between AjaxProxy the remote host
# If you’re behind a proxy server yourself, use these
#PROXY_HOST = ‘proxy.server.com:8080′
#PROXY_USER = ‘yourusername’ # Not required
#PROXY_PASS = ‘yourpassword’ # Required if PROXY_USER is set
LOG_DOMAIN = ‘localhost’ # Restrict logging to this domain
LOG_FAVICON = 0 # Log requests for favicon.ico
PI.load(’proxy.instructions’) # Load the instructions file
[/code]

The instructions file allows you to tell the proxy how it should delay requests. An example;

[code lang="python"]
# On each line, enter two instructions seperated by whitespace
# The first is executed after a request has been received by the proxy but before it forwards it
# The second is executed after the response has been fetched by the proxy but before it returns it to the browser

# The available instructions are;
# wait < creates a delay
# - the delay can be specified a colon then an integer (seconds up to 10)
# - or the word "random" for a random delay of 0 - 10 secs
# fail < the request or response fails - nothing delivered
# end < just outputs a message saying it’s the last instruction without interfering with the request for info only
# - use of this is optional

wait:0 wait:1
wait:random wait:random
wait:10 wait:10
wait:0 wait:0
fail # no need to define a response instruction
end
[/code]

Each line of instructions is used to apply to a single request / response lifecycle. The next request will use the instructions on the next line.

Otherwise, it now dumps the complete request and response (HTTP headers and body) which can be handy for debugging.

A friendly explaination some other time. Meanwhile it’s interesting to try some of the AJAX applications out there - there’s some tails or madness, rage and data loss waiting to be told ( and JPSpan is not entirely innocent either) …

Synchronous Requests == BAD

This is one point where I agree strongly with the name AJAX - remember what that first letter stands for…

To grasp why, it’s worth seeing some examples and discussing which I’ve attmpted before here.

In essence, when you make a synchronous call with XMLHttpRequest, everything else stops and waits for the request to complete. And that means everything - even any intervals you’ve set. You can’t even abort() the request via the readyStateChange property (don’t believe me? try and watch a [browser dependent] crash…).

In other words submitting a synchronous request puts you at the mercy of the network and the server you’re making the request to. While developing on localhost, you’ll probably be unaware of this and living under the illusion that synchronous requests are just fine. But on a live site, if the server happens to get Slashdotted, while you’re busy SJAXing, expect a very long wait and a dead browser - to an end user, particular when using IE, it looks like it’s crashed (if I remember right IE does eventually recover but only after about 5 minutes).

To really get a feel for this you need to see it in action, which I’ll do with the help of a simple Python HTTP server that only accepts on request at a time, then goes into a sleep for 10 seconds before serving the next request. Any other incoming requests have to wait until the server is free to continue working. This sort-of-simulates a web server that’s got too much work to do.

Note if you’re using Windows and don’t have Python installed, do so - it’s completely painless. Make sure you add the python executable to your PATH (i.e. Start > Control Panel > (Administration) > System > Advanced > Environment Variables and add C:\Python24\ at the end of the PATH variable).

The code for the server is simply;

[code lang="python"]
#!/usr/bin/python
# minimal web server. serves files relative to the
# current directory.
#
# See: http://effbot.org/librarybook/simplehttpserver.htm
# http://docs.python.org/lib/module-SimpleHTTPServer.html
# http://docs.python.org/lib/module-SocketServer.html
#
# IMPORTANT QUOTE:
# “[the basic SocketServer implementations] process requests
# synchronously; each request must be completed before the
# next request can be started.”

import SimpleHTTPServer
import SocketServer
import time;

PORT = 8000

class MyHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
def do_GET(self):
SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
# Go to sleep for 10 secs after serving request
time.sleep(10);

httpd = SocketServer.TCPServer((”", PORT), MyHandler)

print “serving at port”, PORT
httpd.serve_forever()
[/code]

Put this in some directory on your filesystem, in a file named server.py. Now add another file called response.txt to the same directory, containing simply;

[code]
Hello World!
[/code]

Finally add a third file called ajax.html to the same directory, containing the following;

[code lang="xml"]

Do it!


[/code]

With that done, you can now fire up the server script - run server.py. For Windows users that’s something like;

[code]
C:\path\to\server.py
[/code]

If you put the python executable in your path or;

[code]
C:\Python24\python.exe C:\path\to\server.py
[/code]

if you didn’t.

The server is now listening on port 8000 so you should be able to access from your browser via the URL http://localhost:8000.

Follow the link to the ajax.html. Now click “doIt” a few times and see what happens - sometimes you’ll get a quick response (an alert that says “Hello World!”). Other times you’ll get a longish wait, during which your browser will be hung up. Now imagine users starting to fidget…

Then, to really see why synchronous requests are a bad idea, try running Apache Benchmark at the same time (it’s provided with Apache 2 as an executable for Windows users) e.g. from a DOS box;

[code]
C:\Progra~1\Apache2\utils\ab.exe -n 50 http://localhost:8000/response.txt
[/code]

Now try clicking on that “doIt” link a few times. Is this something you really want your users to experience?

Otherwise, another thing to try to really grasp the difference between synchronous and asynchronous requests is watching code execute with Venkman.

The bottom line here is remembering the Internet has instability built in - it’s a network you don’t control and can (and will) vary in percieved responsiveness, like when they release the verdict on Michael Jackson, complete with video.

The only two possible exceptions I’d make to this are for an Intranet application, where the end users are in shouting distance, or perhaps in the special case of a sychronous multipart requests (work work only in Mozilla anyway) - see this Sync Multipart demo and notice how the browser “recovers” while the request is still in progress.

So, to repeat, Synchronous Requests == BAD.