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?
Posted by csev at June 21, 2008 07:37 AM