With all the buzz (and to some extent, let's be honest, hype) apart the newly sexy and relabelled AJAX, I'm beginning to wonder about the continuing applicability of some of the design principles I have applied to web applications for the past 6 years.
When contrasting the new "Javascript sexy" world with the previous "Javascript crappy" one, many people speak as if the only reason we shied away from script-heavy web applications was that they were to say the least difficult to debug. That is of course not the whole story - it's easy to forget the browser story a few years ago was much worse than it is now, with IE and Netscape offering two completely different DHTML models and other browsers going their own strange way. So things are much better now if for no other reason than that everybody understands "getElementById" (one of the last reasons for browser sniffing involves AJAX and will be greatly mitigated by IE7, but that's another story)
But there was yet another issue: aside from those browsers that didn't have support for any version of Javascript let alone a DOM (I recall at one point using the not entirely helpful argument that their users probably didn't have any money anyway), towards the turn of the century it became common practice for organisations to block or disable Javascript for security reasons.
That led to the logical conclusion: if you want to expose your site or application broadly on the public internet, you can't assume that Javascript will be available.
Hence the rule: No mission-critical client script. The ASP.NET validators exemplify this approach: by default they will be triggered on the client, but the server-side validation is always triggered in any case, so that even if Javascript is blocked the control still works (or if it doesn't, it's for a different reason).
And that's the way we've approached things in an online world where client script may or may not be enabled: we've had to treat it as something that improves the user experience where it's available, but without which the application still functions.
AJAX-enabled applications could be designed the same way, but I can confidently predict that the non-AJAX user experience will be much more painful than if the UI were designed with full page refreshes in mind, since the design choices that would normally be made to mitigate the limitations of that approach are likely not to have been made, or may simply not be practical without providing two different versions of the site. In other words, everything that is unpleasant and cumbersome about a non-AJAX web application is likely to be even more so for AJAX applications being used er, without AJAX.
To give a roughly analogous example: you may recall when framesets were in vogue (before they were recognised as evil), we had the element to contain markup to display typically for browsers that did not support framesets or had them disabled. Now, let's be honest: how often was this feature used in a way much more helpful than the following:
It appears that your browser does not support frames, or has them disabled. Shame.
Sooooooooooooooo...I'd be very interested to hear what people think: have we finally moved on to a stage where it can safely be assumed for most purposes that client script will be enabled?