Ajax Best Practices

I am grappling with bestpractice guidelines for Ajax, especially for detecting whether javascript isenabled. Having a slideshow stuck onthe first slide or an update panel not updating is not a disaster, but havingimportant info lost in a nonfunctioning CascadingDropDown, CollapsiblePanel, orAccordion could be very bad.

I have been researching thison the web and it is pretty confusing. From what I have found so far, the most important best practices appearto be: 1) Notify users (of Ajax usage, browser requirements, and probableoccurrence of page updates) and 2) don't create anything that doesn't work ifjavascript is not available in the user's browser.

I am interested in whatothers are doing with regard to Ajax best practices – at a practicallevel. Do you provide notification ofAjax usage and requirements? Do youdetect whether javascript is enabled and have options in place if it is not? Do you ever avoid using Ajax in crucial performanceareas?

I am using Ajax cautiouslywith good results so far, but worry about using some of the controls in certainsituations. Any feedback from those whoare more experienced in this exciting technology would be greatly appreciated.

http://www.fieldexpert.com/2006/01/03/ajax-best-practices-dont-break-back/

http://www.fieldexpert.com/2006/01/04/ajax-best-practices-dont-break-bookmarks/

http://www-03.ibm.com/able/resources/ajaxaccessibility.html#best

Should add that I will use Ajax in Intranet apps where I can guarantee that javascript is available. I only use it for its practical applications in improving forms. I don't confuse useful asynchronous requests with gimmicky dhtml.

Those are fantastic questions, and imo what this forum should be about (more than the bazillion questions about how come my UpdatePanel doesn't work with control X...)

Myself, I feel that a mix of approaches as you describe work best. The first line of defense would be to write (as much as possible) code that is compatible w/o JS. You then can write the js code to replace actions and whatnot, if available.

I feel like the 'notification' thing sorta falls short in most cases, as it's too often used as a cop-out "Well, we tell them they need js enabled, so we can pretty much do as we please now"

I've considered a detection scheme, though not implemented it, where the Master page first checks for the existence of a session variable (call it "ajaxed" or something). If it's not there, it renders a small js script that makes an async call back to the server to set said variable. w/o the variable set, subsequent pages render in 'legacy' mode that dont' require js at all. if the variable is already set, then the page renders in 'ajax' mode. This would obviously result in a lot more code, so that's why I haven't done it yet.

I think for crucial operations, I'd definitely make sure that the user has a non-ajax alternative somehow, favor being given to the first method if possible for the scenario in question. I actually *thought* that the original idea of the 'extenders' was to do just that, but I haven't worked with them lately since in my experience I can do the same as what I need for them with less js downloaded to the client.