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.m...@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 > >