Ajax stands for Asynchronous Javascript and XML. In a nutshell, it is a method to interact with the server and send data back and forth without having to refresh the whole page like we used to have to. Instead of the <form> submitting to a separate page, the Javascript hits a file on the server with the given variables, and that PHP or ASP or VBScript file returns the result string based on the input, and the Javascript parses it again to put it out anywhere on the page. For more information on what Ajax is and how to do it, please see the links on the sidebar, down below, under the category “Technical Resources”.
I’ve implemented Ajax on a number of different occasions, and based on my experience, I will discuss what I like about it, and where it should be implemented, and where it should NOT be implemented.
Ajax, first of all, is a great techonology that I love using. I will write some negative things about Ajax down the article but nonetheless, I’m making my position very clear about this whole technology. I love it.
The greatest strength of Ajax is of course the usability and the speed of it. Using Ajax speeds up processes that require interaction with the database and what not, and reduces the load on your server. This is very significant especially if you have a large website with lots of traffic. A couple of kilobytes saved each time an Ajax module kicks in to do the job can significantly reduce site traffic and server load. It also makes it very fast for the user, and it makes your website look slick and professional. Check out this online quiz module I’ve been working on. I also discussed the advantages that facebook has over myspace and other networking websites in this previous post as well.
Another great advantage of Ajax is that it is a culmination of existing technologies and nothing new, which means most browsers have no problem handling it whatseover. It is completely functional on IE and FF, so there are no big holes to jump to be able to use this technology. And the server requirements are easy to satisfy – any conventional server running PHP or ASP can provide the back-end scripting for you.
The downside of Ajax is this, however – the Ajax calls are done through Javascript and search engines currently cannot search results that Javascript queries return. Also, because of the way AJAX is constructed, you never really see a straight-up URL in the code – it’s always broke into pieces with all the GET variables and what not! So anything that comes up as a result of an Ajax call should be considered invisible to the search engines.
I implemented another use of Ajax on my own site, in the portfolios section. I realized soon that my portfolio details are NOT being indexed by search engines at that point, so as you can see, I added a simple link that shows all my portfolio work on a separate page. This should give exposure to that page and do the trick!
Also, Ajax is not completely secure. The headers can be modified when it’s sent out. Using some Firefox add-ons, you can easily modify the Javascript that is being executed, which means you can put in whatever variable you want into the Ajax module. So you cannot use this on any applications that require security, and involves secure information such as user data etc. These kind of data should only be handled through regular PHP files with a secure PHP Session set up. For another interesting article relating to online security and secure web applications, read this post.
So basically it comes down to this – Any articles, descriptions and what not should NOT be done through Ajax, unless you absolutely want the slick effect. It’s not as search-engine friendly, and it’s just an overkill to go that far. Ajax should be used in E-Commerce websites for dropping items into shopping carts. It could be used for online polls or quizzes. It could be used for signing up to email newsletters.
