- From: Michaela Merz <michaela.merz@hermetos.com>
- Date: Tue, 10 Feb 2015 11:35:05 -0600
- To: Marc Fawzi <marc.fawzi@gmail.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
LOL .. good one. But it's not only about whether or not s-xhr should be depreciated. It's also about the focus and scope of the browsers teams work. m. On 02/10/2015 11:28 AM, Marc Fawzi wrote: > 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:35:32 UTC