- From: Ashley Gullen <ashley@scirra.com>
- Date: Tue, 10 Feb 2015 14:47:07 +0000
- To: George Calvert <george.calvert@loudthink.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CAABs73gy1JHhTskBqwyz3qTnAu0W-BGCMHs6fwq-erNoRVboaw@mail.gmail.com>
I am on the side that synchronous AJAX should definitely be deprecated, except in web workers where sync stuff is OK. Especially on the modern web, there are two really good alternatives: - write your code in a web worker where synchronous calls don't hang the browser - write async code which doesn't hang the browser With modern tools like Promises and the new Fetch API, I can't think of any reason to write a synchronous AJAX request on the main thread, when an async one could have been written instead with probably little extra effort. Alas, existing codebases rely on it, so it cannot be removed easily. But I can't see why anyone would argue that it's a good design principle to make possibly seconds-long synchronous calls on the UI thread. On 9 February 2015 at 19:33, George Calvert <george.calvert@loudthink.com> wrote: > I third Michaela and Gregg. > > > > It is the app and site developers' job to decide whether the user should > wait on the server — not the standard's and, 99.9% of the time, not the > browser's either. > > > > I agree a well-designed site avoids synchronous calls. BUT — there still > are plenty of real-world cases where the best choice is having the user > wait: Like when subsequent options depend on the server's reply. Or more > nuanced, app/content-specific cases where rewinding after an earlier > transaction fails is detrimental to the overall UX or simply impractical to > code. > > > > Let's focus our energies elsewhere — dispensing with browser warnings that > tell me what I already know and with deprecating features that are > well-entrenched and, on occasion, incredibly useful. > > > > Thanks, > George Calvert >
Received on Tuesday, 10 February 2015 14:47:37 UTC