Re: do not deprecate synchronous XMLHttpRequest

You either block the JS event loop or you don't. If you do, I'm not sure
how a long running synchronous call to the server won't result in "this
script is taking too long" alert and basically hold up all execution till
it's done. What am I missing? If you want to synchronize tasks you can
promises or callbacks or (in ES6/7) I'm sure other ways too

On Fri, Feb 6, 2015 at 10:38 AM, Michaela Merz <michaela.merz@hermetos.com>
wrote:

>  Well yeah. But the manufacturer of your audio equipment doesn't come
> into your home to yank the player out of your setup. But that's not really
> the issue here. We're talking about technology that is being developed so
> that people like me can build good content. As long as there are a lot of
> people out there using synchronous calls, it would be the job of the
> browser development community to find a way to make such calls less harmful.
>
> Michaela
>
>
>
> On 02/06/2015 12:28 PM, Marc Fawzi wrote:
>
> I have several 8-track tapes from the early-to-mid 70s that I'm really
> fond of. They are bigger than my iPod. Maybe I can build an adapter with
> mechanical parts, magnetic reader and A/D convertor etc. But that's my job,
> not Apple's job.
>
>  The point is, old technologies die all the time, and people who want to
> hold on to old content and have it play on the latest player (browser) need
> to either recode the content or build adapters/hosts/wrappers such that the
> old content will think it's running in the old player.
>
>  As far as stuff we build today, we have several options for waiting
> until ajax response comes back, and I'm not why we'd want to block
> everything until it does. It sounds unreasonable. There are legitimate
> scenarios for blocking the event loop but not when it comes to fetching
> data from a server.
>
>
>
>
>
> On Fri, Feb 6, 2015 at 9:27 AM, Michaela Merz <michaela.merz@hermetos.com>
> wrote:
>
>>
>> Well .. may be some folks should take a deep breath and think what they
>> are doing. I am 'just' coding web services and too often I find myself
>> asking: Why did the guys think that this would make sense? Indexeddb is
>> such a case. It might be a clever design, but it's horrible from a coders
>> perspective.
>>
>> Would it have been the end of the world to stick with some kind of
>> database language most coders already are familiar with? Same with (sand
>> boxed) file system access. Google went the right way with functions trying
>> to give us what we already knew: files, dirs, read, write, append.  But
>> that's water under the bridge.
>>
>> I have learned to code my stuff in a way that I have to invest time and
>> work so that my users don't have to. This is IMHO a good approach.
>> Unfortunately - some people up the chain have a different approach.
>> Synchronous calls are bad. Get rid of them. Don't care if developers have a
>> need for it. Why bother. Our way or highway. Frankly - I find that
>> offensive.  If you believe that synchronous calls are too much of a problem
>> for the browser, find a way for the browser to deal with it.
>>
>> Building browsers and adding functionality is not and end in itself. The
>> purpose is not to make cool stuff. We don't need people telling us what we
>> are allowed to do. Don't get me wrong: I really appreciate your work and I
>> am exited about what we can do in script nowadays. But please give more
>> thought to the folks coding web sites. We are already dealing with a wide
>> variety of problems: From browser incompatibilities, to responsive designs,
>> server side development, sql, memcached, php, script - you name it. Try to
>> make our life easier by keeping stuff simple and understandable even for
>> those, who don't have the appreciation or the understanding what's going on
>> under the hood of a browser.
>>
>> Thanks.
>>
>> Michaela
>>
>>
>>
>>
>>
>> On 02/06/2015 09:54 AM, Florian Bösch wrote:
>> >
>> >     I had an Android device, but now I have an iPhone. In addition to
>> the popup problem, and the fake "X" on ads, the iPhone browsers (Safari,
>> Chrome, Opera) will start to show a site, then they will lock up for 10-30
>> seconds before finally becoming responsive.
>> >
>> >
>> > Via. Ask Slashdot:
>> http://ask.slashdot.org/story/15/02/04/1626232/ask-slashdot-gaining-control-of-my-mobile-browser
>> >
>> >     Note: Starting with Gecko 30.0 (Firefox 30.0 / Thunderbird 30.0 /
>> SeaMonkey 2.27), synchronous requests on the main thread have been
>> deprecated due to the negative effects to the user experience.
>> >
>> >
>> >
>> > Via
>> https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
>> >
>> >     Heads up! The XMLHttpRequest2 spec was recently changed to prohibit
>> sending a synchronous request whenxhr.responseType is set. The idea behind
>> the change is to help mitigate further usage of synchronous xhrs wherever
>> possible.
>> >
>> >
>> > Via
>> http://updates.html5rocks.com/2012/01/Getting-Rid-of-Synchronous-XHRs
>> >
>> >
>>
>>
>>
>
>