Is this correct:
If the response for any reason does not come immediately but
e.g. in 20 seconds (or never!) the whole browser page is like
dead, keyboard dead, mouse clicking has no effect, the user
becomes angry and desperate, goes away from your page and
never comes back. Or ...?
The user does not necessarily get to go away because synchronous
requests can block the entire browser, so no navigation options are
functional while the request is going on (obviously that can vary
depending on the browser, but is true of IE 6 at absolute minimum). IE 6
also crashes (with a 'do you want to tell Microsoft about this' dialog
on XP) if you attempt to shut it down while a synchronous request is
incomplete.
It has appeared to me that the most common reason for using synchronous
requests is precisely that they do block the browser, preventing any
user interaction. The alternative would be to write code that
managed/coordinated the multiple asynchronous triggers of code execution
(user triggered events and HTTP XML responses), possibly involving
actively blocking user input. Coding this type of thing is obviously
more complex than allowing the side effects of a synchronous request to
render it moot. But that does not mean the effort should not be part of
any AJAX design.
When AJAX was formally proposed the suggested architecture explicitly
included a management/coordination/sequencing layer on the client
labelled "the AJAX Engine". Over time the AJAX buzzword has been
degraded to refer to any XML HTTP request based background loading
system, and the "AJAX Engine" notion has mostly fallen by the wayside.
Probably precisely because it is the difficult part to handle. The needs
of asynchronous request management, coordination and sequencing will
vary considerably between application contexts so no single general
"AJAX Engine" would be appropriate; either being well over the top in
some contexts and/or significantly inadequate it others. Thus while
various 'frameworks' attempt to offer AJAX in reality they rarely go
much beyond providing a wrapper around the HTTP XML request/response
process and mostly leave "AJAX Engine" part of the problem to the
problem to the individual using the 'framework'. (Though some (but
nowhere near all) frameworks do include request queuing and even UI
blocking facilities).
Presented with a need, not having any 'solution' presented to them on a
plate in various 'frameworks', and a task as complex as designing and
creating their own "AJAX Engine" layer, it cannot be surprising that
people would choose employing synchronous requests as there easiest way
out of the situation. And without vigorous/rigorous QA testing
(including the testing of responses to system/server and network
failures of various sorts) it is entirely possible that they may get the
impression of having gotten away with it.
Richard.
