W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: do not deprecate synchronous XMLHttpRequest

From: Michaela Merz <michaela.merz@hermetos.com>
Date: Tue, 10 Feb 2015 11:35:05 -0600
Message-ID: <54DA4149.9000901@hermetos.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC