views:

42

answers:

3

Say I've been tasked to architect a product that will have a browser-based front end.
The sales team wants a snazzy app. The product management team want to make the product cost effective (right through the maintenance phase)

Now assume that the technical team gets to make the call (i wish :)) whether to give the users a 'rich' look & feel that sites like stackoverflow/facebook or to give them something from the 2006 era... with this bunch of considerations thrown in..

  1. The product life is envisaged to be around 6 years
  2. The product maintenance team should not need to refactor code to match future browsers
  3. The product maintenance team will only enhance business functionality
    ..and a whole lot of related stuff like this

.. would you recommend that ajax be used? If yes, what gives me that guarantee that the UI(ajax framework) I use today will continue to work with no change over the next 2-3 browser versions?

EDIT: Please don't assume that I have anything against AJAX. I've been working on DHTML since 1999 and ajax since before it was called ajax :) I've also been working on server side components that have not needed to change since 2002 just because they were coded to a spec.

Having said that I've got first hand experiences of how much 'fail gracefully' code I'd have to write just to keep these capricious browsers happy. Anyway, thanks for all your answers and I guess I'm back to implementing 'fail-gracefully' code yet again.

+3  A: 

Generally, any framework is used for many years and as such ajax has been around quite some time. Additionally, browser change/updates are very sparse at the moment and we still have a 60% usage of ie6 if that is a tell of any sort.

Generally, architect your system/solution with the idea of fallback solution in case of ajax/jquery frameworks not being available. Use the frameworks to extend the UI features and functionality but, at a base without them it would still have functionality.

Joe Garrett
Also note that if you're using locally hosted versions of jQuery, changes to jQuery upstream are going to have no effect on your usage
Mala
I love jQuery. I think its the bee's-knees, but 6 years is a long time to take your statement at face value. Thanks though. I feel a bit better :)
Ryan Fernandes
A: 

IMHO, Ajax is not such a bad guy. Why do you think using AJAX will doom your product? If you use AJAX to provide UI richness, and also you have a fear of failing of the same, you can think of keeping a fallback mechanism. There are even other frameworks like WPF, Silverlight etc for RIA. Ajax is quite stable now (I am referring about AJAX in MS .NET, because AJAX otherwise is a wise old guy now). Silverligt is also getting quite stable. I am seeing some issues with WPF, but you can look at that too.

Kangkan
A: 

You might already know this, but ajax has become part and parcel of modern Web development in the past two or three years; it's simply assumed that, if you have quality people, your Web app will use ajax. We don't really even use the term much anymore; more often it's simply something that's implied when someone says "jQuery", etc.

Modern JavaScript libraries provide a good deal of insulation from browser changes, although your developers will have to exercise self restraint in not making use of the latest proprietary features of the browsers if things are to be cross-browser compliant. There are also higher level stacks such as Google Web Toolkit that do a lot in abstracting the low level stuff away, although I wouldn't necessarily recommend them (or recommend against them).

Whether your situation requires a modern Web application, a more traditional application or a set of static Web page is something you'll need to determine on the basis of the resources you have. As someone else has said, it's good to work in a graceful degradation in cases where an older browser is encountered.

Eric W.