I got a question about whether or not to use Ajax in a new project from a former student. Here is my answer.

Your tech lead is right in that doing Ajax directly and writing it all from Javascript is crazy – browser differences drive you nuts and you really never can be sure that things work across browsers until you have been in production for a while. I wrote some code in Sakai that used XHTMLRequest directly in Javascript about three years ago – I was nervous for about a year after the code went into production. There were never any reported bugs – but the code was really simple – nothing like the Ajax of today.
What your tech lead *might* be saying is that they have a web framework that they like and he does not know how to do Ajax in that framework. If I knew the framework it would be helpful – word like Struts, Java Server Faces (JSF), Velocity, Spring Web Flow, Tapestry, would give me a clue – perhaps he is nervous – if I was a JSF shop I would be nervous about Ajax. If you are writing portlets – that might mean that Ajax is technically difficult in that environment – but I don’t know for sure. I know Ajax is technically difficult in the Portlet environment in the purely standards world – but vendor implementations may have clever workarounds.
One problem with Ajax is accessibility – it is still an open issue – progress is being made – but if your application needs accessibility 100% – avoiding Ajax is probably a good idea.
However with all that said against Ajax, the browser issue is kind of a non-issue – if none of the above are show stoppers – the key is to use a library for Ajax – most use JQuery – in SI539 we used Prototype:
http://jquery.com/
http://www.prototypejs.org/
I like prototype because it is easy as a developer. But real pros prefer jquery because it is cleaner in how it does its thing.
With lots of web applications out there using these libraries – there is safety in numbers – by following the crowd – your app will be no worse then the rest. With Google using Ajax for virtually all its applications – folks whose browsers don’t support Ajax well – generally get new browsers.
So for me, this is how I come down on Ajax – (a) If you are making a web site that is trying to be sticky – you hope users get addicted to the site – and your development environment works with Ajax – definitely use Ajax and (b) if you are building something that people are forced to use (like CTools at UM) avoid Ajax except perhaps where it is really necessary – and then make sure to provide an accessible option.
When users are forced to use an application – accessibility can not be ignored. For sites that are trying to build a community from random people around the world – a better/more functional/more usable site is more likely to attract and keep people – and yes accessibility is compromised – but most startup efforts are trying to show that their idea is successful to get the next round of $$ anyways. So they cut corners in lots and lots areas including accessibility. Not pretty but it is the reality of making prototype stuff.
I would also note that accessibility is sadly pretty lousy in many non-Ajax applications as well – so sometimes Accessibility is a bit of a red herring – folks say “Uh we can’t do Ajax because of accessibility” and then you ask – “Are we going to build an accessible site?” and then the answer is “No, we don’t have time for that but we plan to fix it later” – usually sadly later turns into never as prototype code gets pressed into production.
Did that make sense?