Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27191 > unrolled thread

Synchronous XMLHttpRequest deprecated

Back to article view | Back to comp.lang.javascript

Contents

  Synchronous XMLHttpRequest deprecated Chuck Anderson <seemysig@thisis.invalid> - 2015-04-04 17:34 -0600
    Re: Synchronous XMLHttpRequest deprecated Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2015-04-05 08:09 +0800
    Re: Synchronous XMLHttpRequest deprecated Luuk <luuk@invalid.lan> - 2015-04-05 18:06 +0200
      Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-04-05 10:42 -0700
        Re: Synchronous XMLHttpRequest deprecated Luuk <luuk@invalid.lan> - 2015-04-05 22:04 +0200
      Re: Synchronous XMLHttpRequest deprecated "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-05 22:59 +0200
        Re: Synchronous XMLHttpRequest deprecated Chuck Anderson <seemysig@thisis.invalid> - 2015-04-05 23:09 -0600
          Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 10:20 +0000
    Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-05 23:41 +0200
      Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 14:11 +0200
        Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 13:23 +0000
          Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 15:36 +0200
            Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 18:26 +0000
              Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-06 20:18 +0200
              Re: Synchronous XMLHttpRequest deprecated Denis McMahon <denismfmcmahon@gmail.com> - 2015-04-06 18:35 +0000
                Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-06 21:51 +0000
                  Re: Synchronous XMLHttpRequest deprecated "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-06 23:33 +0200
                Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 01:13 +0200
        Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 09:16 +0200
          Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 12:51 +0200
            Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 14:55 +0200
              Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-07 14:23 +0000
                Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 17:41 +0200
              Re: Synchronous XMLHttpRequest deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-07 15:37 +0200
                Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 16:53 +0200
                  Re: Synchronous XMLHttpRequest deprecated Tim Streater <timstreater@greenbee.net> - 2015-04-07 16:03 +0000
                    Re: Synchronous XMLHttpRequest deprecated Silvio <silvio@internet.com> - 2015-04-07 17:47 +0200

Page 2 of 2 — ← Prev page 1 [2]

#27223

On 04/07/2015 12:51 PM, Thomas 'PointedEars' Lahn wrote:
> Silvio wrote:
>
>> On 04/06/2015 02:11 PM, Thomas 'PointedEars' Lahn wrote:
>>> They who can read have the advantage here.  It is a *warning*, not an
>>> error message.  The developer can disable the display of warnings.
>>> They do not even have to use the Console.
>>
>> The warning is not the problem. But the underlying sentiment is that the
>> feature is benign
>
> Gibberish.
>
>> and it expresses at least the desire to remove the feature at some point.
>
> Non sequitur.  It says that those requests *in the main thread* are
> deprecated.
>

Nitpicking. If someone depends on them being allowed in the main thread 
the potential problem is real.

>
> *Popups* are not user-friendly, which is why they are blocked by default.
>

That depends. In most of my applications for synchronous requests I am 
talking about users of my web-applications expecting they can access 
their "documents" by opening them in browser windows/tabs.

>
> No, the programmer cannot foresee how long it takes a server to respond.
>

In theory he can not but that is irrelevant. In theory my pages and 
embedded images could take forever to load as well making the 
application unusable in the first place.

This is a typical bullshit argument from know it alls who think they are 
able to judge what is best for the world in general and then bully 
everyone who disagrees with them.

>
> Your short attention span and/or insufficient research is *your* problem.
> The fact that synchronous request handling in the main thread *blocks* the
> browser and effectively *prevents the user from using their software*, or
> at least a browser tab or window, until the response is received, and that
> asynchronous request handling does not have that disadvantage, sounds like
> a good argument to me.
>

It is a good argument for preferring asynchronous requests, not for 
disallowing/removing synchronous ones (yeah, yeah, only on the main 
thread and not anytime soon).

>
> You cannot know if the timeout occurred because the server could not respond
> in time or because it could not respond at all.  How many synchronous
> requests are you going to make in order to find out, blocking the user with
> each one?
>

I would make only one. If the request times out in, say, a couple of 
seconds then I would show an error message that the server is not able 
to respond in a timely fashion and it is likely an error has occurred.

>
> That does not mean it is a good thing.  Your logic is flawed.
>

No it is not. The deprecation originates from a knee jerk reaction from 
a couple of browser devs and solves no actual problem that sticks out. 
In fact, only if it ever results in an actual removal of the feature 
there will be heaps of unnecessary problems. In the meantime it causes a 
lot of stir with people who see the warning come up in their browser 
consoles and think something may be wrong. Many users do check the 
console, you know.

[toc] | [prev] | [next] | [standalone]

#27226

In article <5523d3ad$0$2946$e4fe514c@news.xs4all.nl>, Silvio
<silvio@internet.com> wrote:

>On 04/07/2015 12:51 PM, Thomas 'PointedEars' Lahn wrote:

>> No, the programmer cannot foresee how long it takes a server to respond.
>>
>
>In theory he can not but that is irrelevant. In theory my pages and 
>embedded images could take forever to load as well making the 
>application unusable in the first place.
>
>This is a typical bullshit argument from know it alls who think they are 
>able to judge what is best for the world in general and then bully 
>everyone who disagrees with them.

PointyHead is a well known bully and arsehole.

>> You cannot know if the timeout occurred because the server could not respond
>> in time or because it could not respond at all.  How many synchronous
>> requests are you going to make in order to find out, blocking the user with
>> each one?
>
>I would make only one. If the request times out in, say, a couple of 
>seconds then I would show an error message that the server is not able 
>to respond in a timely fashion and it is likely an error has occurred.

In my case, since the server is on the same machine as the user, I
think I can rely on the one sync call that I make completing very
quickly, with no discernible delay at all. Unsurprising since the
script called at that time writes to or three rows of data to an SQLite
database and exits. In my case the browser and server are just
components in the application, and won't need to worry about the same
sort of considerations that apply to websites.

-- 
"I love the way that Microsoft follows standards. 
 In much the same manner as fish follow migrating caribou."
                                               - Paul Tomblin, ASR

[toc] | [prev] | [next] | [standalone]

#27236

On 04/07/2015 04:23 PM, Tim Streater wrote:
> In article <5523d3ad$0$2946$e4fe514c@news.xs4all.nl>, Silvio
> <silvio@internet.com> wrote:
>
>> On 04/07/2015 12:51 PM, Thomas 'PointedEars' Lahn wrote:
>
>>> No, the programmer cannot foresee how long it takes a server to respond.
>>>
>>
>> In theory he can not but that is irrelevant. In theory my pages and
>> embedded images could take forever to load as well making the
>> application unusable in the first place.
>>
>> This is a typical bullshit argument from know it alls who think they
>> are able to judge what is best for the world in general and then bully
>> everyone who disagrees with them.
>
> PointyHead is a well known bully and arsehole.
>
>>> You cannot know if the timeout occurred because the server could not
>>> respond
>>> in time or because it could not respond at all.  How many synchronous
>>> requests are you going to make in order to find out, blocking the
>>> user with
>>> each one?
>>
>> I would make only one. If the request times out in, say, a couple of
>> seconds then I would show an error message that the server is not able
>> to respond in a timely fashion and it is likely an error has occurred.
>
> In my case, since the server is on the same machine as the user, I
> think I can rely on the one sync call that I make completing very
> quickly, with no discernible delay at all. Unsurprising since the
> script called at that time writes to or three rows of data to an SQLite
> database and exits. In my case the browser and server are just
> components in the application, and won't need to worry about the same
> sort of considerations that apply to websites.
>

Sounds plausible.

I have a similar situation. I use a server-side HTML-component framework 
that employs a generic JS script to collect client-side events, send 
them to the server and patch the page with the HTML deltas returned from 
the request.

But we have now learned that this is potentially dangerous and could 
seriously harm our users by freezing their browser tabs.

So please stop doing that... If you do I will too.

[toc] | [prev] | [next] | [standalone]

#27230

Silvio wrote:

> On 04/07/2015 12:51 PM, Thomas 'PointedEars' Lahn wrote:
>> Silvio wrote:
>>> On 04/06/2015 02:11 PM, Thomas 'PointedEars' Lahn wrote:
>>>> They who can read have the advantage here.  It is a *warning*, not an
>>>> error message.  The developer can disable the display of warnings.
>>>> They do not even have to use the Console.
>>> The warning is not the problem. But the underlying sentiment is that the
>>> feature is benign
>>
>> Gibberish.
>>
>>> and it expresses at least the desire to remove the feature at some
>>> point.
>>
>> Non sequitur.  It says that those requests *in the main thread* are
>> deprecated.
> 
> Nitpicking.

No, context matters.  You claimed that the feature of synchronous XHR *on 
the whole* is on the way out because of that warning.  It is not.

> If someone depends on them being allowed in the main thread
> the potential problem is real.

There is no problem at the moment.  You are making one, driven by 
irrationality – fear.

>> *Popups* are not user-friendly, which is why they are blocked by default.
>
> That depends. In most of my applications for synchronous requests I am
> talking about users of my web-applications expecting they can access
> their "documents" by opening them in browser windows/tabs.

It is the 21st century.  For various good reasons, popup *windows* are no 
longer state-of-the-art.

>> No, the programmer cannot foresee how long it takes a server to respond.
>
> In theory he can not but that is irrelevant.

No, it is not irrelevant, and it is not theoretical at all.  It is a 
*practical* problem that has no solution except to avoid it.  Which you have 
been recommended to do.

> In theory my pages and embedded images could take forever to load as well 
> making the application unusable in the first place.

False analogy.  You are ignoring here that those resources are loaded in a 
way that it does *not* block the browser, or browser tabs or windows, 
different to synchronous XHR.
 
> This is a typical bullshit argument from know it alls who think they are
> able to judge what is best for the world in general and then bully
> everyone who disagrees with them.

You should have someone professional look at that inferior complex of yours.  
Nobody is bullying you into anything.  With apologies to JMS: You have been 
told by several people, including, through the developer console, by browser 
developers, that, in essence, it is foolish to implement a Web application 
this way.  You can continue to do it, but at least the truth is where it 
needs to be.

>> You cannot know if the timeout occurred because the server could not
>> respond in time or because it could not respond at all.  How many 
>> synchronous requests are you going to make in order to find out,
>> blocking the user with each one?
> 
> I would make only one. If the request times out in, say, a couple of
> seconds then I would show an error message that the server is not able
> to respond in a timely fashion and it is likely an error has occurred.

AISB, if you only make one request with one timeout, then you do not know if 
you were too fast (i.e. your timeout was too short for the *current* server 
load), or if it could not work at all.  At least a second request would be 
needed, and it would have to be synchronously handled as well.  That way 
lies madness.

>> That does not mean it is a good thing.  Your logic is flawed.
> 
> No it is not. The deprecation originates from a knee jerk reaction from
> a couple of browser devs

Who happen to develop the browsers, many of them in their free time, for 
free.  I am not (yet?) one of them.  I am only the one telling you that 
there is no logic in trying to complain about that here, and that there are 
valid reasons for giving that warning.  Go on, shoot the messenger.

> and solves no actual problem that sticks out.

Fallacy.  The problem is that people are using synchronous requests because 
it is *convenient* for *them*, without being aware or caring of, the 
consequences, based on wrong design decisions driven by flawed reasoning 
caused by lack of experience.  As you so readily demonstrate here.

> In fact, only if it ever results in an actual removal of the feature
> there will be heaps of unnecessary problems.

Doubtful.  You can read all over the Web that you should avoid synchronous 
requests, and why.  There are valid reasons to make them anyway, but what 
you are referring to is not one of them.  (JFYI: I have been using them for 
loading scripts in a way that I can be sure that they are loaded, but that 
is going to change thanks to HTML5 – the difference here being that scripts 
have always been blocking.)

> In the meantime it causes a lot of stir

*You* are the one causing the stir, trying to bully people into doing what 
you want them to do because of your little insignificant use case.

> with people who see the warning come up in their browser consoles and 
> think something may be wrong. Many users do check the console, you know.

Utter nonsense.  I daresay that most users do not even know about the 
developer console – because they are not developers.  You are making a 
typical mistake of a Web developer: assuming that most people use their 
browser in the same way that us Web developers do.

I am not going to continue to discuss with you unless you show some manners, 
including a real name.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27233

On 04/07/2015 03:37 PM, Thomas 'PointedEars' Lahn wrote:
>
> *You* are the one causing the stir, trying to bully people into doing what
> you want them to do because of your little insignificant use case.
>
>> with people who see the warning come up in their browser consoles and
>> think something may be wrong. Many users do check the console, you know.
>
> Utter nonsense.  I daresay that most users do not even know about the
> developer console – because they are not developers.  You are making a
> typical mistake of a Web developer: assuming that most people use their
> browser in the same way that us Web developers do.
>
> I am not going to continue to discuss with you unless you show some manners,
> including a real name.
>

The stir in this case does come from (currently about a dozen) actual 
users, whatever you dare say. I can run the whole stuff async but since 
the users delegate (parts of) their application access to their own 
customers and they dislike having to tell them to trust our "popups", 
which are actually just additional tabs inside the same 
domain/application they prefer us to avoid the blocker.

Since you probably have no actual users and live alone in your ideal 
world this most likely makes no sense to you at all.

Too bad about every newsgroup seems to have its own self appointed know 
it all who can not help himself from meddling in threads without the 
intent to add anything constructive but just to demonstrate his own genius.

[toc] | [prev] | [next] | [standalone]

#27234

In article <5523ef84$0$2911$e4fe514c@news.xs4all.nl>, Silvio
<silvio@internet.com> wrote:

>On 07/04/2015 15:37, Thomas 'PointedEars' Lahn wrote:
>>
>> *You* are the one causing the stir, trying to bully people into doing what
>> you want them to do because of your little insignificant use case.
>>
>>> with people who see the warning come up in their browser consoles and
>>> think something may be wrong. Many users do check the console, you know.
>>
>> Utter nonsense.  I daresay that most users do not even know about the
>> developer console – because they are not developers.  You are making a
>> typical mistake of a Web developer: assuming that most people use their
>> browser in the same way that us Web developers do.

That should be " ... that we web ... ".

>> I am not going to continue to discuss with you unless you show some manners,
>> including a real name.

>Too bad about every newsgroup seems to have its own self appointed know 
>it all who can not help himself from meddling in threads without the 
>intent to add anything constructive but just to demonstrate his own genius.

Glad to see you've got PointyHead bang to rights.

Too bad he has the manners of a pig; he could be of some use to
society. Contrast his approach with David Empson over on
uk.comp.sys.mac and comp.sys.mac.system. There you have someone with a
great depth of knowledge on the subject, which he shares freely and in
a non-judgemental way, in long, useful, and detailed posts.

-- 
HAL 9000:    Dave.  Put down those Windows disks.  Dave.  DAVE!

[toc] | [prev] | [next] | [standalone]

#27237

On 04/07/2015 06:03 PM, Tim Streater wrote:
>
> Glad to see you've got PointyHead bang to rights.
>
> Too bad he has the manners of a pig; he could be of some use to
> society. Contrast his approach with David Empson over on
> uk.comp.sys.mac and comp.sys.mac.system. There you have someone with a
> great depth of knowledge on the subject, which he shares freely and in
> a non-judgemental way, in long, useful, and detailed posts.
>

Yes, I have come across several such gems. Each one experienced and 
empathic people who really set out to help the community.

Quite a contrast from the self righteous loud-mouths.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web