Ajax >> JavaScript >> Web Applications
Ten Ajax Drawbacks
Not all technologies are applicable in all scenario. With increasing number of tools and frameworks, one should be very choosy about the technologies being used in the project. There are multiple open source projects catering the same need. For example there is DOJO, Prototype, YUI, GWT, Mootools etc. which help in building Rich Internet Applications.
Here in this article, I will discuss some AJAX drawbacks. Ajax as we know is used for providing asynchronous behavior in web applications as with desktop applications. Ajax is definitely a wonderful invention but due to some of the AJAX drawbacks, it can not be applied every where specially critical business applications. This is primarily because of Javascript.
AJAX Drawbacks List
1) Browser back button doesn’t work properly with Ajax. When someone presses the back button in browser then the user is shown the last page loaded by the browser. The browsers don’t remember the partial page refreshes being done by using Ajax. Hence an application which asks its users to click back button and make some corrections in the input will not be able to work properly.
2) Bookmarking becomes difficult with Ajax. This is because of the fact that the browser address bar URL remains same when Ajax requests are sent. So if you are browsing Google Maps then you can’t simply bookmark any location by using Ctrl+D in IE. There is a separate URL suggested by Google Maps which has co-ordinates appended to it so that the bookmarks as expected. But every application can’t provide such separate bookmark links to users.
3) Use of Javascript slows down the application. I have seen applications which make heavy use of Ajax and hence the browser needs to do more work. There is definitely a performance difference between showing a static HTML page than processing javascript events. The older generation of browsers isreally awful in this context. Hence this is one of the serious AJAX drawbacks for browsers like IE6.
4) One of the AJAX Drawbacks is that AJAX based applications are difficult to debug than synchronous applications (which use JSP, Servlets for complete page refreshes). Though there are tools and browser extensions to debug Ajax code (Firebug, Fiddler2 etc.) but not everyone is aware of them.
5) The Ajax code is written in HTML or js files and these are downloaded by the browser. So anyone can see your source code for generating Ajax requests. Once the hackers know the URL and parameters to generate Ajax requests, they can very easily generate hoax Ajax requests to your server. So security is also one of the issues.
6) Due to the asynchronous nature, now user can keep on generating requests even when he has not received response for earlier requests. This can lead to scenario where more requests are generated than the server can handle and hence you are forced to increase the capacity of your servers.
7) Accessibility for disabled is also an issue with Ajax based applications. It is true that using Ajax is a smart way of doing things but not everyone is born smart in this world. The synchronous way is what everyone can connect to. So the applications designed for disabled should not use Ajax.
8) If you are writing an application and then thinking of making it seo optimized then better don’t use Ajax (or use minimal). This is because the search engines don’t understand Ajax and they need a proper URL for indexing the content which is one of the AJAX Drawbacks for websites that want to reach out in search engine results
I am not saying that Ajax is something which is dangerous to use. In fact, one can achieve very good user experience using with Ajax as done in Gmail. But one should consider the above points before making any decision.
Do share what you think of these AJAX drawbacks.
JavaScript Tutorials
Local and Global Variables in JavaScript
How to use value of one variable as name for another variable in javascript
Comments
Anon
Old, but just stumbled on it and…., yep, not documented enough, let’s take them 1 by 1.
1. Use the browsers history (also mentioned above)
2. Don’t seem to remember wanting full pages loaded with ajax. 50% true, i too sometimes hate the missuse of this.
3. IE6 is long dead my friend, even at the time of this writing it had a BIG CROSS on its head. Also this only applies for big queries, u have to be an idiot to get a full 1k rows DB table with ajax whitout using pagination and at the rate the computing power today is increasing, no need to worrie too much about this (well, maybe sometimes).
4. If you don’t know about them, you’re no web developer my friend (maybe you’re a plumber).
5. Don’t know how to guard yourself from this, go drive a cab, web development is not for you.
6. Same as 5 and 4, maybe you can get a job at the post office, i think it suits you.
7. Part of the web developer job description, ALWAYS build and design for special cases (it all goes down to if you want to or if the client said so)
8. I think this is the only point I can agree, mostly with the minimal part, not all sites are Facebook, so….you get it…
Conclusion: more or less of the above. You just need to use it when it’s necessary, it’s not a “use and abuse” thing, also you have to be VERY carefull when using it due to the mentioned security flaws, there are plenty of ways to stop them, but, yes, you cannot get 100%.
Clay
9 + 10 are good points, but you may not be aware of features available for the other points:
1+2) 1 and 2 are very related. You can do both with javascript, in fact see how gmail does it. Click on an email, hit the back button. Click on the email again, copy the URL, paste it in a new tab and you’re right at that email. Here’s a tutorial on how to do this in GWT: http://code.google.com/webtoolkit/doc/latest/DevGuideCodingBasicsHistory.html. And JQuery has a plugin for it: http://tkyk.github.com/jquery-history-plugin/
3+8) The claim is that javascript heavy applications increase the load on both the browser and server. I agree there is an up front cost to load a javascript app on the client, however the initial load of the app contains static files which are easy for a server to handle. And once the app is loaded, it makes much smaller HTTP requests which reduces the load on the server since it doesn’t have to re-render a whole page, and on the client which also doesn’t have to render the whole page.
4) True, Firebug helps, as does the debugger in GWT/Eclipse so that you can step through code but it’s imperfect.
5) Security: This is a problem for HTML apps too. Anyone can see how the page POSTs the data to the server. It’s probably better to say that an Ajax app will have a larger “surface area” in terms of URLs to POST to that need security validation but both approaches are not immune.