W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: =[xhr]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 1 Aug 2014 08:33:00 -0500
Message-ID: <CAAWBYDBo7Ahfv7mC8meo58p_pst9G2Y6ncp6EgoFF3fri81BVA@mail.gmail.com>
To: nmork_consultant@cusa.canon.com
Cc: public-webapps <public-webapps@w3.org>
On Aug 1, 2014 8:16 AM, <nmork_consultant@cusa.canon.com> wrote:
>
> In this case, a freeze on all browser operations is desirable.  The
thread cannot be interrupted, and if it is interrupted (by browser closure
or other such) then the transactions are immediately stopped and no update
will occur (this is the most desirable outcome.)

Assuming you're handling transactions yourself, using async XHR has no
effect on this. (The browser doesn't provide any transactions for you.)

Async XHR doesn't continue after tab closure.

> Async is not desirable, since it gives control back to the browser and
the user has a false impression that interaction may be ok or even
desirable.  In this case it is not, it is an all stop until complete
requirement.

You can throw up a spinner to indicate that if you want, and get the same
effect. The spinner solution lets you do more things, too, such as
providing feedback or other information to the user. (Or just allowing
hover effects to work - freezing the main thread restricts a *lot* of
things.)

> I use both async and sync xmlhttprequests, and they both have their
place.  Please do not deprecate sync requests simply because you cannot
imagine where they would be desirable.  When they are needed, they are
ABSOLUTELY needed and async requests are not only NOT desirable, but can
lead to potentially disastrous results.

Sync XHR offers you literally nothing over async XHR besides a little bit
of restrictive simplicity. There is absolutely no situation in which sync
XHR is actually required.

~TJ
Received on Friday, 1 August 2014 13:33:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC