Re: do not deprecate synchronous XMLHttpRequest

On Tuesday, February 10, 2015, Marc Fawzi <marc.fawzi@gmail.com> wrote:

> 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?
>

The event fires async, at the time we update the property. There is no way
to synchronously observe an XHR.


>
> On Tue, Feb 10, 2015 at 9:44 AM, Elliott Sprehn <esprehn@chromium.org
> <javascript:_e(%7B%7D,'cvml','esprehn@chromium.org');>> wrote:
>
>>
>>
>> On Tuesday, February 10, 2015, Marc Fawzi <marc.fawzi@gmail.com
>> <javascript:_e(%7B%7D,'cvml','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____
>>> >
>>> >
>>>
>>>
>