- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Tue, 10 Feb 2015 09:28:26 -0800
- To: Michaela Merz <michaela.merz@hermetos.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Here is a really bad idea: Launch an async xhr and monitor its readyState in a while loop and don't exit the loop till it has finished. Easier than writing charged emails. Less drain on the soul. Sent from my iPhone > On Feb 10, 2015, at 8:48 AM, Michaela Merz <michaela.merz@hermetos.com> wrote: > > No argument in regard to the problems that might arise from using sync > calls. But it is IMHO not the job of the browser developers to decide > who can use what, when and why. It is up the guys (or gals) coding a > web site to select an appropriate AJAX call to get the job done. > > Once again: Please remember that it is your job to make my (and > countless other web developers) life easier and to give us more > choices, more possibilities to do cool stuff. We appreciate your work. > But must of us don't need hard coded education in regard to the way we > think that web-apps and -services should be created. > > m. > >> On 02/10/2015 08:47 AM, Ashley Gullen wrote: >> 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 >> <mailto: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 17:29:18 UTC