views:

176

answers:

9

The following is a very vague and incomplete list of advantages and pitfalls that I am aware of. I would really appreciate it if anyone more knowledgeable in this area could help expend on these...

Advantages...

  • User experience can be improved with a faster and seemingly more natural UI.
  • Content and functionality from many different sources can be more easily mashed-up together on a single UI.

Pitfalls...

  • Security and authentication is harder to get right.
  • It requires client-side scripting to manipulate the UI, which causes it to inherit all of that technique’s limitations (for example, script execution speed, browser inconsistencies, fewer and less useful [EDIT] Unit Testing tools, etc).
  • The Same Origin Policy limits the sources that information can be obtained from.
+5  A: 

One of the "problems" a user might experience using WebPage made with Ajax is the loss of the "Back" feature of the browsers. Its not exactly an Ajax limitation but it becomes a problem from the usability point of view.

Megacan
I hate this aspect of AJAX with a passion.
Paul Nathan
I don't like Web Pages all made with Ajax.
Megacan
This is a problem but there are solutions, if not native ones, in things like ReallySimpleHistory (http://code.google.com/p/reallysimplehistory/)
annakata
+2  A: 

Reliant on javascript being enabled/available - can easily mean content isn't available to search engines.

Rich Bradshaw
+1  A: 

Maintaining page consistency is an issue: When you update one item, you sometimes have to update others too. Typical example: you have a list of items, then you click to filter them. Now you need to update your paging element as well.

Otávio Décio
+2  A: 

Frankly, I'd challenge both of your pitfall assertions.

AJAX provides another method of access, but fundamentally it's not doing anything that couldn't be done by the end-user via his browser already.

Manipulating a web page UI without client-side scripting would be both extremely cumbersome for the client and a burden to the server (which makes the point about execution speed laughable - JS at the client is incredibly responsive), browser inconsistencies are just not the problem today that they used to be, and Firebug exists.

annakata
+1  A: 

Advantages:-

More flexible/responsive user interface.

Autocomplete and dynamic menus become possible.

Pitfalls...

Lots of little Ajax requests will increase server loading by a factor of 10.

Each little AJAX gee-whiz gizmo will need to be backed by a server side program.

Security (if required) needs to be implemented in a way that will work for each AJAX http request.

Whats not really an issue:-

Script execution speed. Most client PCs are overspecced and those AMD Turon cores are probably not doing anything else with thier 3Ghz of instructions.

Brower incompatibilities. The standard AJAX libraries are actually the solution to this problem. I have seen DOJO and Prototype used purely because it was the easiest way to overcome browser incompatibilities.

Debugging. There are many and various Firefox plugins and a few IE modules which will help you debug the Javascript. Personally I have seen more problems on the server side (just your typical bugs, but harder to find when hidden behind an httprequest) so I would concentrate on unit testing the server side before hooking it up to the browser.

James Anderson
+1  A: 

Using a library such as JQuery helps minimize the last pitfall mentioned. Security/Authentication can be achieved by appending hashed keys or other methods to each call and validating it server side.

I would suggest returning a JSON object if multiple areas need to be updated, it allows much more flexibilty and minimizes data sent.

The advantages is not only speed but more importantly being able to execute code server side. Things such as ratings, comments are perfect candidates because of this.

Avoid over-ajaxing everything, if your essentially loading most of a page altered your getting very little gain for a lot of complexity. This is probably the hardest part, knowing when you should use it - it can confuse users as they have to notice all the changes.

savageguy
+1  A: 

In relation to what ocedecio said if you have more than one form on a page and have them all in their own Update Panels or some other Ajax form controls you need to be sure that you update any panels that may be effected by any of the form controls actions.

For example if you have a set of Tabs (maybe using the Tab control) and on one tab you allow an admin to Create a new user, and on another tab you have some sort of User operations that you select a user from a drop down box, that box will be outdated if you don't post back after a new user is added to the database or don't update the box contents.

Sean
A: 

[annakata]
AJAX provides another method of access, but fundamentally it's not doing anything that couldn't be done by the end-user via his browser already.

I can't disagree with you on this. XmlHttpRequest does allow you to supply credientials through the Http Authentication header. With regard to the "Dymanic Script API" technique of performing asyncronous calls, would you advise using this technique to get round Single Origin Policy restrictions, and if so, could you suggest a way to securly pass credentials to the server?

[annakata]
Manipulating a web page UI without client-side scripting would be both extremely cumbersome for the client and a burden to the server (which makes the point about execution speed laughable - JS at the client is incredibly responsive), browser inconsistencies are just not the problem today that they used to be, and Firebug exists.

When I referred to slow performance I was comparing dynamic DOM manipulation against rendering markup. I was under the impression that it is slower in some browsers to dynamically change the DOM on the client side compared with using server controls and manipulating them on the server-side and then simply asking the browser to render the result.. If this isn’t the case then I concede the point.

It seems that some browsers are much faster at manipulating the DOM (Chrome compared to IE for example), but I also understand that this will be improved by all browser vendors, spurred on by the popularity of Ajax.

Thanks very much for your comments.

Andy McCluggage
+1  A: 

I don't really agree with one point that James Anderson mentioned :

"Lots of little Ajax requests will increase server loading by a factor of 10."

Another way of looking at this is that even though the number of connections maintained by the server may be more because of AJAX, the amount of processing load may actually reduce. For example, in a normal web page, the server has to do all the markup generation whereas using AJAX, we can simply pass "Data" from the server to the client and then have JavaScript generate the necessary markup to show that data on the client end. When you do this for a large number of users, the reduction in server load may more than compensate for the server load caused due to maintaining more connections.

Sanket