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

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

Re: Synchronous XMLHttpRequest deprecated

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Synchronous XMLHttpRequest deprecated Robert Zeurunkl <bzeurunkl@gmail.com> - 2022-06-22 16:44 -0700
    Re: Synchronous XMLHttpRequest deprecated doctor@doctor.nl2k.ab.ca (The Doctor) - 2022-06-23 00:27 +0000
      Re: Synchronous XMLHttpRequest deprecated Jan Bruns <ebay@abnuto.de> - 2022-06-23 08:46 +0000
    Re: Synchronous XMLHttpRequest deprecated Scott Sauyet <scott@sauyet.com> - 2022-06-24 07:43 -0700
    Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-25 12:06 +0200
      Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2022-06-25 09:47 -0700
        Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-26 00:47 +0200
          Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2022-06-26 09:38 -0700
            Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-26 19:02 +0200
              Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2022-06-26 15:38 -0700
                Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-27 09:31 +0200
                  Re: Synchronous XMLHttpRequest deprecated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2022-06-28 10:48 -0700
          Re: Synchronous XMLHttpRequest deprecated The Natural Philosopher <tnp@invalid.invalid> - 2022-06-27 17:49 +0100
            Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-28 09:41 +0200
              Re: Synchronous XMLHttpRequest deprecated The Natural Philosopher <tnp@invalid.invalid> - 2022-06-28 11:59 +0100
                Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-28 15:19 +0200
                Re: Synchronous XMLHttpRequest deprecated John Harris <niam@jghnorth.org.uk.invalid> - 2022-06-28 18:27 +0100
                  Re: Synchronous XMLHttpRequest deprecated The Natural Philosopher <tnp@invalid.invalid> - 2022-06-28 18:42 +0100
      Re: Synchronous XMLHttpRequest deprecated The Natural Philosopher <tnp@invalid.invalid> - 2022-06-27 17:49 +0100
        Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-28 09:40 +0200
          Re: Synchronous XMLHttpRequest deprecated The Natural Philosopher <tnp@invalid.invalid> - 2022-06-28 11:48 +0100
            Re: Synchronous XMLHttpRequest deprecated Arno Welzel <usenet@arnowelzel.de> - 2022-06-28 15:20 +0200

Page 1 of 2  [1] 2  Next page →

#40917 — Re: Synchronous XMLHttpRequest deprecated

Google seems to think that all software HAS a user interface.  Or even a user.

Synchronous server requests are a perfectly reasonable thing to do in some circumstances.  And I agree with the author that such a decision belongs to the application developer, not the browser maker.

[toc] | [next] | [standalone]

#40918

In article <9585d114-082a-49b0-9c3c-185708e2a256n@googlegroups.com>,
Robert Zeurunkl  <bzeurunkl@gmail.com> wrote:
>
>Google seems to think that all software HAS a user interface.  Or even a user.

Is Google that stupid?

>
>Synchronous server requests are a perfectly reasonable thing to do in some circumstances.  And I agree with the author that such a decision belongs to the application developer, not the browser maker.
>

Hence async.
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
Saying good things is evil when they are lies. -unknown Beware https://mindspring.com

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

#40920

The Doctor:

>>Synchronous server requests are a perfectly reasonable thing to do in
>>some circumstances.  And I agree with the author that such a decision
>>belongs to the application developer, not the browser maker.
>>
>>
> Hence async.

Ehm, What's the name of the JS construct to blocking-wait for signals?

With more API calls becoming async-styled, the more difficult it becomes 
to  collect related pieces of code in a block. And keeping deeply nestedd 
prenthesis in sync obviously also isn't very meaningful. And all this to 
make websites use up a complete CPU. 


Gruss

Jan Bruns

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

#40922

Robert Zeurunkl wrote:

> Synchronous server requests are a perfectly reasonable thing to do in 
> some circumstances. And I agree with the author that such a decision 
> belongs to the application developer, not the browser maker.

I think you misunderstand the relationship.  Browser makers are in the
job of helping end users, not application developers.  To convince a
browser maker to add, remove, or alter a feature, developers need to
demonstrate how it will be of benefit to users.  If they cannot do so,
the vendor has no conceivable reason to make the change.

So to argue for future synchronous requests, you will need to show that
users will be better off if it's added.

The reason it was deprecated is that the vendors were convinced by 
advocates for users that the risks to users significantly outweighed
the benefits.  Sites that freeze waiting for a response that never
comes are considered a much bigger hazard than the inconvenience
caused to developers.  Feel free to try to convince the community
otherwise.  But I think it's a (very steep!) uphill battle.

  -- Scott

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

#40924

Robert Zeurunkl:

> Google seems to think that all software HAS a user interface.  Or
> even a user.

Which is the case as long as the request is executed in a browser.

> Synchronous server requests are a perfectly reasonable thing to do in
> some circumstances.  And I agree with the author that such a decision
> belongs to the application developer, not the browser maker.

What kind of *browsers* don't have a user interface?

And using a request which blocks the whole UI until there is a response
from the server *is* a bad thing.

-- 
Arno Welzel
https://arnowelzel.de

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

#40925

On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:

> What kind of *browsers* don't have a user interface? 

They are called Headless Browsers:

<https://en.wikipedia.org/wiki/Headless_browser>

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

#40926

Michael Haufe (TNO):

> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
> 
>> What kind of *browsers* don't have a user interface? 
> 
> They are called Headless Browsers:
> 
> <https://en.wikipedia.org/wiki/Headless_browser>

Yes, I'm aware of this. But are these are relevant in this context? How
many applications use headless browsers *and* need to use XMLHttpRequest?


-- 
Arno Welzel
https://arnowelzel.de

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

#40930

On Saturday, June 25, 2022 at 5:47:44 PM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):
> > On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote: 
> > 
> >> What kind of *browsers* don't have a user interface? 
> > 
> > They are called Headless Browsers: 
> > 
> > <https://en.wikipedia.org/wiki/Headless_browser>
> Yes, I'm aware of this. But are these are relevant in this context? How 
> many applications use headless browsers *and* need to use XMLHttpRequest?

Applications that have an automated QA process use this often. You can test scenarios such as:

"When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
such as PowerShell 7.

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

#40931

Michael Haufe (TNO):

> On Saturday, June 25, 2022 at 5:47:44 PM UTC-5, Arno Welzel wrote:
>> Michael Haufe (TNO):
>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote: 
>>>
>>>> What kind of *browsers* don't have a user interface? 
>>>
>>> They are called Headless Browsers: 
>>>
>>> <https://en.wikipedia.org/wiki/Headless_browser>
>> Yes, I'm aware of this. But are these are relevant in this context? How 
>> many applications use headless browsers *and* need to use XMLHttpRequest?
> 
> Applications that have an automated QA process use this often. You can test scenarios such as:
> 
> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

I dont't understand why this requires a syncronous XMLHttpRequest. Test
tools like Cypress can wait for events.

> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
> such as PowerShell 7.

And web scraping needs XMLHttpRequest? Why?

-- 
Arno Welzel
https://arnowelzel.de

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

#40933

On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO): 

> > Applications that have an automated QA process use this often. You can test scenarios such as: 
> > 
> > "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

> I dont't understand why this requires a syncronous XMLHttpRequest. Test 
> tools like Cypress can wait for events.

> > You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM 
> > such as PowerShell 7.

> And web scraping needs XMLHttpRequest? Why?

You seem to be drifting or making a point that wasn't expressed clearly.
Which question are you asking?

Is it about Headless Browsers + XHR or is it about Headless Browsers + Synchronous XHR?

You don't need synchronous XHR with the existence of async/await and events as you've mentioned.

For the web scraping: you don't *need* it, but if you have an anemic CLI or host environment, a DOM+JS environment can be far easier.

If I'm in a browser (headless or otherwise) I can near trivially walk the hyperlinks of the domain and collect information information such as email addresses. It's just a DFS or BFS walk. The XHR object even has the ability to provide a DOM as a result of a request directly without parsing.

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

#40934

Michael Haufe (TNO):

> On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
>> Michael Haufe (TNO): 
> 
>>> Applications that have an automated QA process use this often. You can test scenarios such as: 
>>>
>>> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"
> 
>> I dont't understand why this requires a syncronous XMLHttpRequest. Test 
>> tools like Cypress can wait for events.
> 
>>> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM 
>>> such as PowerShell 7.
> 
>> And web scraping needs XMLHttpRequest? Why?
> 
> You seem to be drifting or making a point that wasn't expressed clearly.
> Which question are you asking?

My question was, why *synchronous* XHR is *required* for tests or web
scraping. I have done testing with headless browsers myself a lot and
never needed *synchronous* XHR ever.

Also "web scraping" means first of all just to send requests and wait
for the result. There is no issue at all if this is done with
asynchronous XHR.

> If I'm in a browser (headless or otherwise) I can near trivially walk
> the hyperlinks of the domain and collect information information such
> as email addresses. It's just a DFS or BFS walk. The XHR object even
> has the ability to provide a DOM as a result of a request directly
> without parsing.
And why does the XHR to be synchronous?


-- 
Arno Welzel
https://arnowelzel.de

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

#40948

On Monday, June 27, 2022 at 2:32:04 AM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):
> > On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote: 
> >> Michael Haufe (TNO): 
> > 
> >>> Applications that have an automated QA process use this often. You can test scenarios such as: 
> >>> 
> >>> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared" 
> > 
> >> I dont't understand why this requires a syncronous XMLHttpRequest. Test 
> >> tools like Cypress can wait for events. 
> > 
> >>> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM 
> >>> such as PowerShell 7. 
> > 
> >> And web scraping needs XMLHttpRequest? Why? 
> > 
> > You seem to be drifting or making a point that wasn't expressed clearly. 
> > Which question are you asking?
> My question was, why *synchronous* XHR is *required* for tests or web 
> scraping. I have done testing with headless browsers myself a lot and 
> never needed *synchronous* XHR ever. 

Agreed

> Also "web scraping" means first of all just to send requests and wait 
> for the result. There is no issue at all if this is done with 
> asynchronous XHR.
> > If I'm in a browser (headless or otherwise) I can near trivially walk 
> > the hyperlinks of the domain and collect information information such 
> > as email addresses. It's just a DFS or BFS walk. The XHR object even 
> > has the ability to provide a DOM as a result of a request directly 
> > without parsing.
> And why does the XHR to be synchronous?

Right, I think we agree on all points. I don't see any use case for synchronous XHR here either. Walking a graph is parallelizable.

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

#40937

On 25/06/2022 23:47, Arno Welzel wrote:
> Michael Haufe (TNO):
> 
>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>
>>> What kind of *browsers* don't have a user interface?
>>
>> They are called Headless Browsers:
>>
>> <https://en.wikipedia.org/wiki/Headless_browser>
> 
> Yes, I'm aware of this. But are these are relevant in this context? How
> many applications use headless browsers *and* need to use XMLHttpRequest?
> 
> 
I've written a couple...


-- 
Future generations will wonder in bemused amazement that the early 
twenty-first century’s developed world went into hysterical panic over a 
globally average temperature increase of a few tenths of a degree, and, 
on the basis of gross exaggerations of highly uncertain computer 
projections combined into implausible chains of inference, proceeded to 
contemplate a rollback of the industrial age.

Richard Lindzen

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

#40941

The Natural Philosopher:

> On 25/06/2022 23:47, Arno Welzel wrote:
>> Michael Haufe (TNO):
>>
>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>
>>>> What kind of *browsers* don't have a user interface?
>>>
>>> They are called Headless Browsers:
>>>
>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>
>> Yes, I'm aware of this. But are these are relevant in this context? How
>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>
>>
> I've written a couple...

Can you name them? Or are they just relevant to yourself?

-- 
Arno Welzel
https://arnowelzel.de

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

#40943

On 28/06/2022 08:41, Arno Welzel wrote:
> The Natural Philosopher:
> 
>> On 25/06/2022 23:47, Arno Welzel wrote:
>>> Michael Haufe (TNO):
>>>
>>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>>
>>>>> What kind of *browsers* don't have a user interface?
>>>>
>>>> They are called Headless Browsers:
>>>>
>>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>>
>>> Yes, I'm aware of this. But are these are relevant in this context? How
>>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>>
>>>
>> I've written a couple...
> 
> Can you name them? Or are they just relevant to yourself?
> 
Oh, just relevant to myself. Ive written apps where the easiest solution 
was to implement background tasks from browser to server to update parts 
of the web page whilst a real time job - streaming videos TV or music - 
was happening in 'foreground'

conceptually these tasks could be considered 'headless browsers', and 
they certainly used AJAX style calls and call backs.

But redefining semantics to win arguments doesn't get sound code written 
so if you want to challenge that you wont get a response out of me.

The philosophy part of my name means that I make clear distinctions at 
all levels  between  Kant's 'things in themselves' , and our mental 
*models* of them.

I don't give a flying fuck if my code is 'true object oriented' ' 
procedural' 'synchronous' or 'asynchronous' , 'multithreaded' or 'single 
user' 'headless' 'tailless'..only that it not be 'pointless'.

I leave all that ego boosting semantics to computer scientists. I care 
simply that it works to do the intended job. I am just an engineer.

-- 
“There are two ways to be fooled. One is to believe what isn’t true; the 
other is to refuse to believe what is true.”

—Soren Kierkegaard

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

#40944

The Natural Philosopher:

> On 28/06/2022 08:41, Arno Welzel wrote:
>> The Natural Philosopher:
>>
>>> On 25/06/2022 23:47, Arno Welzel wrote:
>>>> Michael Haufe (TNO):
>>>>
>>>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>>>
>>>>>> What kind of *browsers* don't have a user interface?
>>>>>
>>>>> They are called Headless Browsers:
>>>>>
>>>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>>>
>>>> Yes, I'm aware of this. But are these are relevant in this context? How
>>>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>>>
>>>>
>>> I've written a couple...
>>
>> Can you name them? Or are they just relevant to yourself?
>>
> Oh, just relevant to myself. Ive written apps where the easiest solution 
> was to implement background tasks from browser to server to update parts 
> of the web page whilst a real time job - streaming videos TV or music - 
> was happening in 'foreground'
> 
> conceptually these tasks could be considered 'headless browsers', and 
> they certainly used AJAX style calls and call backs.
> 
> But redefining semantics to win arguments doesn't get sound code written 
> so if you want to challenge that you wont get a response out of me.

What do you mean with "redefining semantics"?

I just asked about the practical *requirement* for *synchronous*
XMLHttpRequest in headless browers which can not be solved with
*asynchronous* XMLHttpRequest.

I also asked if you can name the apps you have written, so one can see
their relevance. If something is only relevant for yourself than it does
not justify to keep the technology as a whole just because you
personally like to use it.


-- 
Arno Welzel
https://arnowelzel.de

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

#40946

On 28/06/2022 11:59, The Natural Philosopher wrote:

   <snip>
> I leave all that ego boosting semantics to computer scientists. I care 
> simply that it works to do the intended job. I am just an engineer.

But not an engineer who recognises what he's done. That's not something 
that inspires confidence in others.

   John

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

#40947

On 28/06/2022 18:27, John Harris wrote:
> On 28/06/2022 11:59, The Natural Philosopher wrote:
> 
>    <snip>
>> I leave all that ego boosting semantics to computer scientists. I care 
>> simply that it works to do the intended job. I am just an engineer.
> 
> But not an engineer who recognises what he's done. That's not something 
> that inspires confidence in others.
> 

Oh dear: another 'literalist'

I recognise that I have created code that meets the specification.
In the end it's all just bits in silicon.





>    John
> 


-- 
In todays liberal progressive conflict-free education system, everyone 
gets full Marx.

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

#40936

On 25/06/2022 11:06, Arno Welzel wrote:
> What kind of*browsers*  don't have a user interface?

Lib curl?


-- 
Future generations will wonder in bemused amazement that the early 
twenty-first century’s developed world went into hysterical panic over a 
globally average temperature increase of a few tenths of a degree, and, 
on the basis of gross exaggerations of highly uncertain computer 
projections combined into implausible chains of inference, proceeded to 
contemplate a rollback of the industrial age.

Richard Lindzen

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

#40940

The Natural Philosopher:

> On 25/06/2022 11:06, Arno Welzel wrote:
>> What kind of*browsers*  don't have a user interface?
> 
> Lib curl?

This is not a browser. No, not every library which is able to send HTTP
requests and process the response is a "browser".


-- 
Arno Welzel
https://arnowelzel.de

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web