Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user requests a change. This is meant to increase the web page's interactivity, speed, and usability. However, there are several common mistakes using it, like: using Axaj just for the sake of Ajax, moreover the back button of the browser become unuseful, there might be a delay displaying enhanced GUI widgets, offline content is not supported, concurrent page loading is dramatically slowed down, sensitive information might be sent encrypted, cross-browser implementation is not one of developers primary concerns, concurrent access is not well supported, running the entire application on the client side makes it slower, there is no support for user without a JavaScript enable browser, GUI might change unexpectedly, there are no URLs which may be referred and indexed by users and search engines, pop-up blockers might kill opening windows, there are a lot of asynchronous operations happening in the background which might be difficult to be controlled, inventing new controls which are less intuitive than the classic ones, style and internationalization issues due to partial page rendering, the lack of data posted back from the user, Web traffic cannot be reported for each section of a given site.Web Technologies, Web Frameworks, AJAX, Asynchronous HTTP Request, User-friendly Interfaces

Iulian ILIE NEMEDI

English

Research Papers in Economics

Informatica Economică, nr. 2 (42)/2007 
 
122 
Ajax Mistakes  
 
Iulian ILIE-NEMEDI 
Department of Informatics in Economy, Academy of Economic Studies, Bucharest 
 
Ajax, shorthand for Asynchronous JavaScript and XML, is a web development tech-
nique for creating interactive web applications. The intent is to make web pages feel more re-
sponsive by exchanging small amounts of data with the server behind the scenes, so that the 
entire web page does not have to be reloaded each time the user requests a change. This is 
meant to increase the web page's interactivity, speed, and usability. However, there are sev-
eral common mistakes using it, like: using Axaj just for the sake of Ajax, moreover the back 
button of the browser become unuseful, there might be a delay displaying enhanced GUI wid-
gets, offline content is not supported, concurrent page loading is dramatically slowed down, 
sensitive information might be sent encrypted, cross-browser implementation is not one of de-
velopers primary concerns, concurrent access is not well supported, running the entire appli-
cation on the client side makes it slower, there is no support for user without a JavaScript en-
able browser, GUI might change unexpectedly, there are no URLs which may be referred and 
indexed by users and search engines, pop-up blockers might kill opening windows, there are 
a lot of asynchronous operations happening in the background which might be difficult to be 
controlled, inventing new controls which are less intuitive than the classic ones, style and in-
ternationalization issues due to partial page rendering, the lack of data posted back from the 
user, Web traffic cannot be reported for each section of a given site. 
Keywords: Web Technologies, Web Frameworks, AJAX, Asynchronous HTTP Request, User-
friendly Interfaces 
 
sing Ajax for the sake of Ajax 
Sure Ajax is cool, and developers love 
to play with cool technology, but Ajax 
is a tool, not a toy. A lot of Ajax isn’t seri-
ously needed to improve usability but rather 
experiments in what Ajax can do or trying to 
fit Ajax somewhere where it isn’t needed. 
 
Breaking the back button 
The back button is a great feature of the stan-
dard web site user interface. Unfortunately, 
the back button doesn’t mesh very well with 
JavaScript. Keeping back button functional-
ity is one reason not to go with a pure 
JavaScript web app. Keep in mind however 
that good web design provides the user with 
everything they would need to successfully 
navigate your site, and never relies on web 
browser controls. 
 
Not giving immediate visual cues for click-
ing widgets 
If something I’m clicking on is triggering 
Ajax actions, you have to give me a visual 
cue that something is going on. An example 
of this is GMail loading button that is in the 
top right. Whenever I do something in 
GMail, a little red box in the top right indi-
cates that the page is loading, to make up for 
the fact that Ajax doesn’t trigger the normal 
web UI for new page loading. 
 
Leaving offline people behind 
As web applications push the boundaries fur-
ther and further, it becomes more and more 
compelling to move all applications to the 
web. The provisioning is better, the world-
wide access model is great, the maintenance 
and configuration is really cool, and the user 
interface learning curve is short. However, 
with this new breed of Ajax applications, 
people who have spotty internet connections 
or people who just don’t want to switch to 
the web need to be accommodated as well. 
Just because technology ‘advances’ doesn’t 
mean that people are ready and willing to go 
with it. Web application design should at 
least consider offline access. With GMail it’s 
POP, Backpackit has SMS integration. In the 
Enterprise, it’s web-services. 
U Informatica Economică, nr. 2 (42)/2007 
 
123
 
Don’t make me wait 
With Firefox tabs, I can manage various 
waits at websites, and typically I only have to 
wait for a page navigation. With AJAX apps 
combined with poor network connec-
tivity/bandwidth/latency I can have a really 
terrible time managing an interface, because 
every time I do something I have to wait for 
the server to return a response. However, re-
member that the ‘A’ in AJAX stands for 
‘Asynchronous’, and the interaction can be 
designed so that the user is not prevented 
from continuing to work on the page while 
the earlier request is processed. 
 
Sending sensitive information in the clear 
The security of AJAX applications is subject 
to the same rules as any web application, ex-
cept that once you can talk asynchronously to 
the server, you may tend to write code that is 
very chatty in a potentially insecure way. All 
traffic must be vetted to make sure security is 
not compromised. 
 
Assuming AJAX development is single 
platform development 
Ajax development is multi-platform devel-
opment. Ajax code will run on IE’s 
JavaScript engine, Spidermonkey (Mozilla’s 
JavaScript engine), Rhino (a JavaScript im-
plementation in Java, also from Mozilla), or 
other minor engines that may grow into ma-
jor engines. So it’s not enough just to code to 
JavaScript standards, there needs to be real-
world thorough testing as well. A major ob-
stacle in any serious JavaScript development 
is IE’s buggy JS implementation, although 
there are tools to help with IE JS develop-
ment.  
 
Forgetting that multiple people might be 
using the same application at the same 
time 
In the case of developing an Intranet type 
web application, you have to remember that 
you might have more than one person using 
the application at once. If the data that is be-
ing displayed is dynamically stored in a da-
tabase, make sure it doesn’t go “stale” on 
you. 
 
Too much code makes the browser slow 
Ajax introduces a way to make much more 
interesting JavaScript applications, unfortu-
nately interesting often means more code 
running. More code running means more 
work for the browser, which means that for 
some JavaScript intensive websites, espe-
cially inefficiently coded ones, you need to 
have a powerful CPU to keep the functional-
ity zippy. The CPU problem has actually 
been a limit on JavaScript functionality in the 
past, and just because computers have gotten 
faster doesn’t mean the problem has disap-
peared. 
 
Not having a plan for those who do not en-
able or have JavaScript 
According to the W3 schools browser usage 
statistics, which if anything are skewed to-
wards advanced browsers, 11% of all visitors 
don’t have JavaScript. So if your web appli-
cation is wholly dependent on JavaScript, it 
would seem that you have potentially cut a 
tenth of your audience. 
 
Blinking and changing parts of the page 
unexpectedly 
The first A in Ajax stands for asynchronous. 
The problem with asynchronous messages is 
that they can be quite confusing when they 
pop in unexpectedly. Asynchronous page 
changes should only ever occur in narrowly 
defined places and should be used judi-
ciously, flashing and blinking in messages in 
areas I don’t want to concentrate on harkens 
back to days of the html blink tag. “Yellow 
Fade”, “One Second Spotlight” and other 
similar techniques are used to indicate page 
changes unobtrusively. 
 
Not using links I can pass to friends or 
bookmark 
Another great feature of websites is that I can 
pass URLs to other people and they can see 
the same thing that I’m seeing. I can also 
bookmark an index into my site navigation 
and come back to it later. JavaScript, and Informatica Economică, nr. 2 (42)/2007 
 
124 
thus Ajax applications, can cause huge prob-
lems for this model of use. Since the 
JavaScript is dynamically generating the 
page instead of the server, the URL is cut out 
of the loop and can no longer be used as an 
index into navigation. This is a very unfortu-
nate feature to lose; many Ajax webapps 
thoughtfully include specially constructed 
permalinks for this exact reason. 
 
Blocking Spidering 
Ajax applications that load large amounts of 
text without a reload can cause a big problem 
for search engines. This goes back to the 
URL problem. If users can come in through 
search engines, the text of the application 
needs to be somewhat static so that the spi-
ders can read it. 
 
Asynchronously performing batch opera-
tions 
Sure with Ajax you can make edits to a lot of 
form fields happen immediately, but that can 
cause a lot of problems. For example if I 
check off a lot of check boxes that are each 
sent asynchronously to the server, I lose my 
ability to keep track of the overall state of 
checkbox changes and the flood of checkbox 
change indications will be annoying and dis-
concerting. 
 
Scrolling the page and making me lose my 
place 
Another problem with popping text into a 
running page is that it can affect the page 
scroll. I may be happily reading an article or 
paging through a long list, and an asynchro-
nous JavaScript request will decide to cut out 
a paragraph way above where I’m reading, 
cutting my reading flow off. This is obvi-
ously annoying and it wastes my time trying 
to figure out my place. But then again, that 
would be a very stupid way to program a 
page, with or without AJAX. 
 
Inventing new UI conventions 
A major mistake that is easy to make with 
Ajax is: ‘click on this non obvious thing to 
drive this other non obvious result’. Sure, us-
ers who use an application for a while may 
learn that if you click and hold down the 
mouse on this div that you can then drag it 
and permanently move it to this other place, 
but since that’s it’s not in the common user 
experience, you increase the time and diffi-
culty of learning the application, which is a 
major negative for any application. On the 
plus side, intuitiveness is a function of learn-
ing, and AJAX is popularizing many new 
conventions which will become intuitive as 
time goes by. The net result will be greater 
productivity once the industry gets over the 
intuitiveness hump. 
 
Character Sets 
One big problem with using AJAX is the 
lack of support for character sets. You should 
always set the content character set on the 
server-side as well as encoding any data sent 
by JavaScript. Use ISO-8859-1 if you use 
plain English, or UTF-8 if you use special 
characters, like æ, ø and å (Danish special 
characters) Note: it is usually a good idea to 
go with utf-8 nowadays as it supports many 
languages). 
 
Changing state with links (GET requests) 
The majority of Ajax applications tend to just 
use the GET method when working with 
AJAX. However, the W3C standards state 
that GET should only be used for retrieving 
data, and POST should only be used for set-
ting data. Although there might be no notice-
able difference to the end user, these stan-
dards should still be followed to avoid prob-
lems with robots or programs such as Google 
Web Accelerator. 
 
Not cascading local changes to other parts 
of the page 
Since Ajax/JavaScript gives you such spe-
cific control over page content, it’s easy to 
get too focused on a single area of content 
and miss the overall integrated picture. An 
example of this is the Backpackit title. If you 
change a Backpackit page title, they immedi-
ately replace the title, they even remember to 
replace the title on the right, but they don’t 
replace the head title tag with the new page Informatica Economică, nr. 2 (42)/2007 
 
125
title. With Ajax you have to think about the 
whole picture even with localized changes. 
 
Problem reporting 
In a traditional server-side application, you 
have visibility into every exception, you can 
log all interesting events and benchmarks, 
and you can even record and view (if you 
wish) the actual HTML that the browser is 
rendering. With client-side applications, you 
may have no idea that something has gone 
wrong if you don’t know how to code cor-
rectly and log exceptions from the remotely 
called pages to your database. 
Return on Investment 
Sometimes AJAX can impressively improve 
the usability of an application (a great exam-
ple is the star-rating feedback on Netflix), but 
more often you see examples of expensive 
rich-client applications that were no better 
than the plain HTML versions. 
Mimicing browser page navigation behavior 
imperfectly 
One example of this is blink list Ajax paging 
mechanism on the front page. As you click to 
see another page of links, Ajax fills in the 
next page. Except that if you are used to a 
browser experience, you probably expect to 
go to the top of the page when you hit next 
page, something JavaScript driven page 
navigation doesn’t do. BlinkList actually an-
ticipates this and tries to counteract by ma-
nipulating your scrolling to scroll upwards 
until you hit the top. Except this can be slow 
and if you try scrolling down you will fight 
the upwards scrolling JavaScript and it won’t 
let you scroll down. But then again, that is 
very stupid way to program a page, with or 
without AJAX. 
 
Another Tool 
It seems everyone has forgotten that Ajax is 
just another tool in the toolbox for Web De-
sign. You can use it or not and misuse it or 
not. The old 80/20 rule always applies to ap-
plications (if you cover 80% of what all users 
want/need then you have a viable app) and if 
you lose 11% of your audience because they 
don’t switch on their JavaScript then you 
have to ask yourself if changing your app is 
worth capturing that 11% or stick with 89% 
that are currently using it and move on to 
something else. Also web apps should take 
advantage of all tricks to enable them to 
function quickly and efficiently. If that 
means using JavaScript for some part, Ajax 
for another and ASP callbacks for a third, so 
be it. 
 
References 
• Adams Cameron – Remote Scripting with 
AJAX,O’Reilly, 2005 
• Garrett Jesse James – Ajax: A New Ap-
proach to Web Applications, 
http://www.adaptivepath.com/publications/es
says/archives/000385.php 
• Gehtland Justin, Galbraith Ben, Almaer 
Dion – Pragmatic Ajax, O’Reilly, 2006 
• Mahemoff Michael – Ajax Design Patterns, 
O’Reilly, 2006 
• Perry Bruce – Ajax Hacks, O’Reilly, 2006 
• Perry Bruce – Google Web Toolkit for Ajax, 
O’Reilly, 2007 
 

Remote Scripting with AJAX,O’Reilly,

Ajax Mistakes

http://www.revistaie.ase.ro/content/42/nemedi-nr.2.pdf

Ajax Mistakes

Abstract

Similar works

Full text

Available Versions

Research Papers in Economics