Re: do not deprecate synchronous XMLHttpRequest

Ryosuke:

I understand the reasoning behind the thought. But it is IMHO not the
job of  browser implementations to educated web developers or to tell
them, how things should (not) be done. All I am asking is to keep in
mind that it is us who actually makes the content - the very reason for
browsers to be developed and improved. And - seeing the e-mail address
and hoping that you have some influence on the development of "Safari": 
Please make the necessary improvements so that Safari can be used in a
highly complex script environment. That includes indexeddb/file handle
and the possibilities to export and store arbitrary blobs of data into
the file system (eg. createObjectURL for any kind of data). Thanks.

m.



On 02/06/2015 12:30 PM, Ryosuke Niwa wrote:
>
>> On 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.
>
> In that regard, I'm on the same boat.  I still write simple web apps
in PHP with PostgreSQL instead of Scala/Ruby and a non-schema database
today.  So I totally understand your sentiment.  However,
>
>> 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.
>
> The problem isn't so much that it causes a problem for browser
implementors but rather it results in poor user experience.  While a
synchronous XHR is on the fly, user cannot interact with the page at
all.  With some spinner, etc... UI indicating that the user has to wait,
the user can at least still click on hyperlinks and so forth.
>
> Since browser vendors (and I hope so are other participants of the
working group) are interested in providing better user experience, we
would like websites to use asynchronous XHR.
>
> Having said that, don't worry.  Synchronous XHR isn't going away
anytime soon.  As long as real websites are using synchronous XHR,
browser vendors aren't going to remove/unsupport it.
>
> - R. Niwa
>
>