I got a question about whether or not to use Ajax in a new project from a former student. Here is my answer.<\/p>\n
\nYour 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.
\nWhat 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.
\nOne 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.
\nHowever 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:<\/p>\n