If readyState is async then have set a variable in the readyState change callback and monitor that variable in a while loop :D
What am I missing? On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn <espr...@chromium.org> wrote: > > > On Tuesday, February 10, 2015, Marc Fawzi <marc.fa...@gmail.com> 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 > > > This won't work, state changes are async and long running while loops > result in the hung script dialog which means we'll probably just kill your > page. > > The main thread of your web app is the UI thread, you shouldn't be doing > IO there (or anything else expensive). Some other application > platforms will even flash the whole screen or kill your process if you do > that to warn you're doing something awful. > > > >> >> Sent from my iPhone >> >> > On Feb 10, 2015, at 8:48 AM, Michaela Merz <michaela.m...@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.calv...@loudthink.com >> >> <mailto:george.calv...@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____ >> > >> > >> >>