Re: do not deprecate synchronous XMLHttpRequest

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 <esprehn@chromium.org>
wrote:

>
>
> On Tuesday, February 10, 2015, Marc Fawzi <marc.fawzi@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.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____
>> >
>> >
>>
>>