- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 1 Aug 2014 08:33:00 -0500
- To: nmork_consultant@cusa.canon.com
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <CAAWBYDBo7Ahfv7mC8meo58p_pst9G2Y6ncp6EgoFF3fri81BVA@mail.gmail.com>
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