ARCHIVE: Much Ajax about Nothing
After Google rolled out Google Suggest and Google Maps, it seems like everybody's talking about the XML HTTP Request object that was lying dormant since 1997. Some guys even took it upon themselves to buzzwordify this new way of web development, calling it Ajax - Asynchronous JavaScript And XML, even though they had absolutely no hand in inventing, popularising, or even adopting the XML HTTP Request object early on. I think next time someone comes up with a great idea + implementation, I will assign it a cool acronym myself. Then I can be famous too.
So what is Ajax? What's the XML HTTP Request object and how does it make my life better or richer? To understand how Ajax improves our web surfing experience, let us first take a look at how websites work. When you type in 'www.chir.ag' in your browser's address bar, your browser sends a request to the web server that hosts the 'chir.ag' domain. The web server is setup to respond to all requests for 'chir.ag' and after interpreting what your browser wants, it sends the appropriate web page. It used to be that web servers could only send static files - web pages (html, htm), images (jpeg, gif), audio (wav, au), and video (mpg, avi, mov, ra). But just sending a file isn't fun and doesn't really do much for anyone. Editing html pages by hand is arduous and pretty boring. Hence there were very few 'blogs (or regularly updated online diaries) back in 1997.
Dynamic pages changed everything. Now instead of going to 'www.chir.ag' and having the same fixed html page load each time, I am able to write a short program that runs on the web server and spits out a new web page every time someone goes to my 'blog. That way, I don't have to keep updating the page myself all the time. My program talks to the database on my server, gets a list of all the latest 'blog entries, formats them in a nice way, and sends it to your browser everytime you click here. I did not explicitly write the page that you see, including this one. I just made small entries into a database table (kinda like an Excel file) and the small program running on my web server converts it to a nicely readable web page.
Well the problem with dynamic web pages is that there is no 'state' information in them. By 'state' we mean that unless some nifty coding is used, the web server doesn't really know what's happening for each browser. A good example of a 'state' aware application is an installation program for any software. The first state is probably the 'welcome' or 'read me' screen and when you click next, it asks you where to install the software. A few states/stages later, the software exclaims 'install successful' and proceeds to launch the program. Doing this exact thing on a web page is possible but not in the same way. The simple reason is, when you run the installation program on your computer, it is only running on ONE computer - yours. In comparison, when you are filling out a 10 page form for say, an auto insurance quote online, there could be thousands of others out there who are doing the same on the exact same site; except some are in step 1 of 10 while some are in step 8 of 10. And probably some unlucky ones are in step 12 of 21 because they had to fill extra forms for being involved in an auto accident recently. As you can see, for a web server to remember the state of each users's form-filling-frenzy is not as simple as that of a single program running on a single computer.
Since the web server doesn't really know which state/stage you are on, every time you click 'Next,' your browser has to send all the data about you back to the server, especially your login, session information, current state, security access etc. Doing this is very cumbersome for the user as well as the developer who has to write pretty complex programs to accept your data and then format and store it accordingly. But what happens if you miss a required field or enter some incorrect information, like your birthdate as February 31, 2005? Then the program running on the web server has to send you back to the same page with big red 'required' error messages. If this was a program running on your computer, it would take a mere two lines of code to check if some field was correctly filled in and if not, show some error message.
To decrease the number trips to the web server, most web pages use JavaScript, which is a simple C-like scripting language that runs on the client-side - within your browser. Using simple JavaScript functions, it is possible to validate if the input is in desired format or not. However, to make sure that incorrect data is not sent to the server anyway, the server also checks to see if the input is valid. Thus, now there are two places that can stop you and say 'You must enter your email address to continue.' As if error-checking on the server-end wasn't tedious enough, now the develpers must error-check on the client-end using JavaScript.
So what does this really have to do with Ajax? Hmm... wouldn't it be awesome if somehow there was just one set of error-checking functions, preferably on the server-end, that could be called from both the server and the client sides, WITHOUT re-loading the entire web page? What if you entered a username that was already taken up by someone else and you didn't have to click 'Submit' to find that out? Wouldn't it rock if, as soon as you typed in 'elvis', the web page signaled non-intrusively that "the selected username is not available." While this is not the only thing Ajax can do, it can certainly help the developers with performing seamless error-checking.
To make this work easily, all I have to do is add some JavaScript code to the 'onchange' event of the 'username' textbox. Anytime the 'username' box changes, your browser calls the 'doesUsernameExist(username)' function within a program on my web server. Your browser does not wait to receive any response from my server but instead behaves perfectly normal, letting you move around the page, scroll up/down etc., hence the 'asynchronous' part. During this same time, the program on the web server receives the username entered by you and queries the database to see if anyone else has used it or not. If found, then return 'sorry username taken' or else return 'cool username!' Now the JavaScript running on your computer receives back the return message from the function and it can do whatever it wants with it - show you an annoying warning or smartly turn the textbox field's background slightly red and print the return message to it's right: 'elvis has already entered the building. try something else.'
Ajax is just an acronym for this whole process - accepting input from user, calling a function or two on the web server seamlessly using the XML HTTP Request object, retrieving the response from the web server without stalling the browser, and then depending on the response, change something on the web page - all without the user clicking 'submit' or 'send' at any time. Pretty sweet if you ask me. However, with great power, comes great abuse and looks like everybody and their aunt is now dying to use Ajax on their cooking recipe 'blogs. There are a few places where it's awesome to use Ajax and there are places where there is no need for Ajax. You need Ajax if you're writing dynamic web applications that require complex input validation. You don't need Ajax to make a simple menu.
One thing I don't really like about Ajax is the 'XML' bit. As the whole world sits with arms wide open accepting XML as the sole format for data interchange and sadly data storage, I grow sicker and sicker by the minute, tired of parsing through one nested </yetAnotherClosingItem> tag after </anotherClosingTag>. And that deserves an entire 'blog entry by itself.
So what is Ajax? What's the XML HTTP Request object and how does it make my life better or richer? To understand how Ajax improves our web surfing experience, let us first take a look at how websites work. When you type in 'www.chir.ag' in your browser's address bar, your browser sends a request to the web server that hosts the 'chir.ag' domain. The web server is setup to respond to all requests for 'chir.ag' and after interpreting what your browser wants, it sends the appropriate web page. It used to be that web servers could only send static files - web pages (html, htm), images (jpeg, gif), audio (wav, au), and video (mpg, avi, mov, ra). But just sending a file isn't fun and doesn't really do much for anyone. Editing html pages by hand is arduous and pretty boring. Hence there were very few 'blogs (or regularly updated online diaries) back in 1997.
Dynamic pages changed everything. Now instead of going to 'www.chir.ag' and having the same fixed html page load each time, I am able to write a short program that runs on the web server and spits out a new web page every time someone goes to my 'blog. That way, I don't have to keep updating the page myself all the time. My program talks to the database on my server, gets a list of all the latest 'blog entries, formats them in a nice way, and sends it to your browser everytime you click here. I did not explicitly write the page that you see, including this one. I just made small entries into a database table (kinda like an Excel file) and the small program running on my web server converts it to a nicely readable web page.
Well the problem with dynamic web pages is that there is no 'state' information in them. By 'state' we mean that unless some nifty coding is used, the web server doesn't really know what's happening for each browser. A good example of a 'state' aware application is an installation program for any software. The first state is probably the 'welcome' or 'read me' screen and when you click next, it asks you where to install the software. A few states/stages later, the software exclaims 'install successful' and proceeds to launch the program. Doing this exact thing on a web page is possible but not in the same way. The simple reason is, when you run the installation program on your computer, it is only running on ONE computer - yours. In comparison, when you are filling out a 10 page form for say, an auto insurance quote online, there could be thousands of others out there who are doing the same on the exact same site; except some are in step 1 of 10 while some are in step 8 of 10. And probably some unlucky ones are in step 12 of 21 because they had to fill extra forms for being involved in an auto accident recently. As you can see, for a web server to remember the state of each users's form-filling-frenzy is not as simple as that of a single program running on a single computer.
Since the web server doesn't really know which state/stage you are on, every time you click 'Next,' your browser has to send all the data about you back to the server, especially your login, session information, current state, security access etc. Doing this is very cumbersome for the user as well as the developer who has to write pretty complex programs to accept your data and then format and store it accordingly. But what happens if you miss a required field or enter some incorrect information, like your birthdate as February 31, 2005? Then the program running on the web server has to send you back to the same page with big red 'required' error messages. If this was a program running on your computer, it would take a mere two lines of code to check if some field was correctly filled in and if not, show some error message.
To decrease the number trips to the web server, most web pages use JavaScript, which is a simple C-like scripting language that runs on the client-side - within your browser. Using simple JavaScript functions, it is possible to validate if the input is in desired format or not. However, to make sure that incorrect data is not sent to the server anyway, the server also checks to see if the input is valid. Thus, now there are two places that can stop you and say 'You must enter your email address to continue.' As if error-checking on the server-end wasn't tedious enough, now the develpers must error-check on the client-end using JavaScript.
So what does this really have to do with Ajax? Hmm... wouldn't it be awesome if somehow there was just one set of error-checking functions, preferably on the server-end, that could be called from both the server and the client sides, WITHOUT re-loading the entire web page? What if you entered a username that was already taken up by someone else and you didn't have to click 'Submit' to find that out? Wouldn't it rock if, as soon as you typed in 'elvis', the web page signaled non-intrusively that "the selected username is not available." While this is not the only thing Ajax can do, it can certainly help the developers with performing seamless error-checking.
To make this work easily, all I have to do is add some JavaScript code to the 'onchange' event of the 'username' textbox. Anytime the 'username' box changes, your browser calls the 'doesUsernameExist(username)' function within a program on my web server. Your browser does not wait to receive any response from my server but instead behaves perfectly normal, letting you move around the page, scroll up/down etc., hence the 'asynchronous' part. During this same time, the program on the web server receives the username entered by you and queries the database to see if anyone else has used it or not. If found, then return 'sorry username taken' or else return 'cool username!' Now the JavaScript running on your computer receives back the return message from the function and it can do whatever it wants with it - show you an annoying warning or smartly turn the textbox field's background slightly red and print the return message to it's right: 'elvis has already entered the building. try something else.'
Ajax is just an acronym for this whole process - accepting input from user, calling a function or two on the web server seamlessly using the XML HTTP Request object, retrieving the response from the web server without stalling the browser, and then depending on the response, change something on the web page - all without the user clicking 'submit' or 'send' at any time. Pretty sweet if you ask me. However, with great power, comes great abuse and looks like everybody and their aunt is now dying to use Ajax on their cooking recipe 'blogs. There are a few places where it's awesome to use Ajax and there are places where there is no need for Ajax. You need Ajax if you're writing dynamic web applications that require complex input validation. You don't need Ajax to make a simple menu.
One thing I don't really like about Ajax is the 'XML' bit. As the whole world sits with arms wide open accepting XML as the sole format for data interchange and sadly data storage, I grow sicker and sicker by the minute, tired of parsing through one nested </yetAnotherClosingItem> tag after </anotherClosingTag>. And that deserves an entire 'blog entry by itself.