Re: do not deprecate synchronous XMLHttpRequest

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 <mailto: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
>     >
>     > 
>
>
>