Re: do not deprecate synchronous XMLHttpRequest

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