Re: Updated Javascript Best Practices document


Robert wrote:

I would like your or someone else his/her comment about the
synchronization problems using (asynchronous) Ajax. Because for me it
just gives more problems than it solves.

Please read this webpage that describes the problems when using
asynchronous Ajax:
http://softwaredesign.nl/index.php?pageID=34

I am only an amateur with this, but my thoughts are:-

1. The author in that referred article seems to equate AJAX with
asynchronous. See:-

QUOTE: "The idea behind Ajax is not new. Asynchronous communication has
emerged a number of times as the answer to provide responsive user
interfaces."

QUOTE: "However, if there is any dependency whatsoever, you will need
synchronization. Since Javascript offers no synchronization at all,
this translates to "if your Ajax data transmissions have dependencies
you are in deep ***".

But as far as I am aware, AJAX does have a "synchronous" option, albeit
it means that the browser "hangs" when waiting for the response.

2. That article is useful in pointing out potential pitfalls. But I
am not clear what alternatives/solutions the author in that article is
offering, or indeed thinks are possible, for an open distributed
environment like the internet. Yes there are challenges to be faced,
but unless the author has a better idea, we need to engage imagination
and work with what we have I suppose.

3. QUOTE: "Asynchronous communication can work, but it requires
certain synchronization mechanisms. Mechanisms that do not exist in
Javascript. "

I don't think I agree with this. One could perhaps (subject to
limitations as to number of permitted requests at any time) manage
timing issues (if timing is an issue) by creating a request "list",
accessible to the send() the call-back() function of each request.
Each time a request it is made it would be pushed onto the list. When
a request completes, it would be removed from the list. This then could
let you have control such as:-

(a) Only allowing a given request to start or run its call-back() if
all or certain previous requests have completed.

(b) Allowing you to abort certain requests if a particular kind of
request is made or fails.

(c) Allowing you to abort requests if some particular action is
taken by the client.

Admittedly this does not help with the issue of timing of requests
received at the server, athough I would not be so gloomy as to assume
that this could not be overcome.

Regards

Julian Turner

.