info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Synchronous XMLHttpRequest deprecated
1,120 views
Skip to first unread message
Chuck Anderson
Apr 4, 2015, 7:34:44 PM4/4/15
to
The current Firefox displays this warning in the console when I use a
synchronous XMLHttpRequest.
"Synchronous XMLHttpRequest on the main thread is deprecated because of
its detrimental effects to the end user's experience. For more help
http://xhr.spec.whatwg.org/"
I've read about the reasoning and understand the logic, ... although I
believe this should be a decision left up to the page designer and not
dictated by the browser developers.
That said, ... most all of my synchronous "ajax" requests can be
converted to asynchronous with no detrimental effect.
I do have one case, though, that needs to be synchronous. I have
written a file synch/backup web application for myself using Php, and
JavaScript . It compares - then copies (sync/backup) a list of files on
a local server or on a remote server (using FTP).
During the copy process I provide progress feedback on the list of files
being copied by opening an overlaying div with a table and using
JavaScript to:
1. Create a new table row with the name of the file, it's size and a
faux progress meter (animated gif).
2. Send a synchronous XMLHttpRequest to the local server to actually
delete the file (local, LAN, or FTP remote).
3. Display the result ("deleted or failed") from the synchronous
XMLHttpRequest response.
4. Repeat the above process for every file in the list
Yes, it "locks up" my app during the process, but this is exactly what I
want it to do so I can visualize the progress and see if there any
errors or warnings from the Php copy process.
What it usually does it race through the list, displaying a summary at
the end.
I like the way I implemented this, but it appears it will ultimately
stop working in major browsers. I tried an asynchronous approach, but
it is too complex trying to keep track of the separate XMLHttpRequest
responses - spaghetti.
Is there a way to make this synchronous copy process not be "in the main
thread?"
Is there another way I should implement this - like move to an iframe
(not div) and call a Php script that processes the whole list in one
instance? (I don't like using iframes - and won't it have the same
effect anyway - lock up the page while it processes the list?)
Yes, this could leave the boundaries of a JavaScript forum, but the
XMLHttpRequests are where it starts.
(I also created a web app with Php/JavaScript to play Rummy (with a
local or remote opponent) and it requires synchronous calls so the
display of cards on the screen stays in synch with the players moves.
Losing synchronous requests will destroy that entire app.)
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
synchronous XMLHttpRequest.
"Synchronous XMLHttpRequest on the main thread is deprecated because of
its detrimental effects to the end user's experience. For more help
http://xhr.spec.whatwg.org/"
I've read about the reasoning and understand the logic, ... although I
believe this should be a decision left up to the page designer and not
dictated by the browser developers.
That said, ... most all of my synchronous "ajax" requests can be
converted to asynchronous with no detrimental effect.
I do have one case, though, that needs to be synchronous. I have
written a file synch/backup web application for myself using Php, and
JavaScript . It compares - then copies (sync/backup) a list of files on
a local server or on a remote server (using FTP).
During the copy process I provide progress feedback on the list of files
being copied by opening an overlaying div with a table and using
JavaScript to:
1. Create a new table row with the name of the file, it's size and a
faux progress meter (animated gif).
2. Send a synchronous XMLHttpRequest to the local server to actually
delete the file (local, LAN, or FTP remote).
3. Display the result ("deleted or failed") from the synchronous
XMLHttpRequest response.
4. Repeat the above process for every file in the list
Yes, it "locks up" my app during the process, but this is exactly what I
want it to do so I can visualize the progress and see if there any
errors or warnings from the Php copy process.
What it usually does it race through the list, displaying a summary at
the end.
I like the way I implemented this, but it appears it will ultimately
stop working in major browsers. I tried an asynchronous approach, but
it is too complex trying to keep track of the separate XMLHttpRequest
responses - spaghetti.
Is there a way to make this synchronous copy process not be "in the main
thread?"
Is there another way I should implement this - like move to an iframe
(not div) and call a Php script that processes the whole list in one
instance? (I don't like using iframes - and won't it have the same
effect anyway - lock up the page while it processes the list?)
Yes, this could leave the boundaries of a JavaScript forum, but the
XMLHttpRequests are where it starts.
(I also created a web app with Php/JavaScript to play Rummy (with a
local or remote opponent) and it requires synchronous calls so the
display of cards on the screen stays in synch with the players moves.
Losing synchronous requests will destroy that entire app.)
--
*****************************
Chuck Anderson • Boulder, CO
http://cycletourist.com
Turn Off, Tune Out, Drop In
*****************************
Richard Maher
Apr 4, 2015, 8:09:57 PM4/4/15
to
On 4/5/2015 7:34 AM, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
Thanks for the heads-up!
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
I agree with most of your other points. There must be more behind this.
Synchronous must be interfering with some infrastructure functionality
rather than local app sepcific issues.
Luuk
Apr 5, 2015, 12:06:47 PM4/5/15
to
On 5-4-2015 01:34, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
"User agents are strongly encouraged to *warn* about
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
such usage in *developer* tools "
Since when is Firefox a developer tool?
Michael Haufe (TNO)
Apr 5, 2015, 1:43:05 PM4/5/15
to
<https://www.mozilla.org/en-US/firefox/developer/>
I doubt that was what was intended by the quote anyway...
Luuk
Apr 5, 2015, 4:04:49 PM4/5/15
to
* What's New
- Developer Edition theme
* Known Issues
- Firebug theme is not compatible with Developer Edition theme
(source: https://www.mozilla.org/en-US/firefox/35.0a2/auroranotes/ )
That must be better than the non-developer-edition......
(sigh)
;)
Christoph M. Becker
Apr 5, 2015, 4:59:43 PM4/5/15
to
--
Christoph M. Becker
Silvio
Apr 5, 2015, 5:41:46 PM4/5/15
to
On 04/05/2015 01:34 AM, Chuck Anderson wrote:
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
> I've read about the reasoning and understand the logic, ... although I
> believe this should be a decision left up to the page designer and not
> dictated by the browser developers.
>
It is a bad decision to not leave it to the developer. There is an
> The current Firefox displays this warning in the console when I use a
> synchronous XMLHttpRequest.
>
> "Synchronous XMLHttpRequest on the main thread is deprecated because of
> its detrimental effects to the end user's experience. For more help
> http://xhr.spec.whatwg.org/"
>
> I've read about the reasoning and understand the logic, ... although I
> believe this should be a decision left up to the page designer and not
> dictated by the browser developers.
>
important use of synchronous requests that can not be emulated using
asynchronous ones:
- user triggers an event (onclick for example)
- event code does a synchronous requests
- the response is used to open a new browser window with a URL that is
part of the response
The last part can be any action that is rejected outside user initiated
code. This will not work with any async scenario since an async response
handler does not count as user initiated.
Who came up with this idea for deprecatio?. Can someone point me to the
place where this is (or has been) discussed?
Silvio
Chuck Anderson
Apr 6, 2015, 1:09:47 AM4/6/15
to
find the error console a useful tool.
The idea of eliminating synchronous requests seems to have a strong
foothold in W3.org, Chrome and Mozilla so I'm looking for a simple,
logical alternative to my usage.
Personally ... I think it is a bad idea and not a decision for browser
developers. Web designers should have the right to create a slow
loading page if they so wish.
Message has been deleted
Thomas 'PointedEars' Lahn
Apr 6, 2015, 8:14:07 AM4/6/15
to
Silvio wrote:
> On 04/05/2015 01:34 AM, Chuck Anderson wrote:
>> The current Firefox displays this warning in the console when I use a
>> synchronous XMLHttpRequest.
>>
>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>> its detrimental effects to the end user's experience. For more help
>> http://xhr.spec.whatwg.org/"
>>
>> I've read about the reasoning and understand the logic, ... although I
>> believe this should be a decision left up to the page designer and not
>> dictated by the browser developers.
>
> It is a bad decision to not leave it to the developer.
They who can read have the advantage here. It is a *warning*, not an error
> On 04/05/2015 01:34 AM, Chuck Anderson wrote:
>> The current Firefox displays this warning in the console when I use a
>> synchronous XMLHttpRequest.
>>
>> "Synchronous XMLHttpRequest on the main thread is deprecated because of
>> its detrimental effects to the end user's experience. For more help
>> http://xhr.spec.whatwg.org/"
>>
>> I've read about the reasoning and understand the logic, ... although I
>> believe this should be a decision left up to the page designer and not
>> dictated by the browser developers.
>
> It is a bad decision to not leave it to the developer.
message. The developer can disable the display of warnings. They do not
even have to use the Console.
> There is an important use of synchronous requests that can not be emulated
> using asynchronous ones:
>
> - user triggers an event (onclick for example)
> - event code does a synchronous requests
> - the response is used to open a new browser window with a URL that is
> part of the response
>
> The last part can be any action that is rejected outside user initiated
> code. This will not work with any async scenario since an async response
> handler does not count as user initiated.
friendly, non-blocking, asychronous way?
> Who came up with this idea for deprecatio?. Can someone point me to the
> place where this is (or has been) discussed?
elsewhere.
--
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.
Message has been deleted
Thomas 'PointedEars' Lahn
Apr 6, 2015, 9:38:32 AM4/6/15
to
Tim Streater wrote:
> […] Thomas 'PointedEars' Lahn […] wrote:
>> I do not see your point. Why exactly can that not be done in a user-
>> friendly, non-blocking, asychronous way?
>
> Termination actions. If the user closes the window in my app, the
> unbeforeunload handler runs. This is my last chance to tidy up, and I
> need to be able to run a PHP script and, crucially, to have it
> complete, before the handler exits.
>
> Making an async XMLHttpRequest will mean that the handler will complete
> right away and my PHP script will be aborted by apache. So I make a
> sync request and all behaves as required.
Your application is badly designed if it relies on a “beforeunload” event
listener triggering a synchronously-handled HTTP request.
> […] Thomas 'PointedEars' Lahn […] wrote:
>> I do not see your point. Why exactly can that not be done in a user-
>> friendly, non-blocking, asychronous way?
>
> unbeforeunload handler runs. This is my last chance to tidy up, and I
> need to be able to run a PHP script and, crucially, to have it
> complete, before the handler exits.
>
> Making an async XMLHttpRequest will mean that the handler will complete
> right away and my PHP script will be aborted by apache. So I make a
> sync request and all behaves as required.
Your application is badly designed if it relies on a “beforeunload” event
listener triggering a synchronously-handled HTTP request.
Message has been deleted
Thomas 'PointedEars' Lahn
Apr 6, 2015, 2:20:20 PM4/6/15
to
Tim Streater wrote:
> […] Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Tim Streater wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
>> Your application is badly designed if it relies on a “beforeunload” event
>> listener triggering a synchronously-handled HTTP request.
>
> Gee, I'll have to smack those users harder, then, so they don't click
> on the little red X in the top corner of the window.
No, you have to change the design of your application.
> […] Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Tim Streater wrote:
>>> […] Thomas 'PointedEars' Lahn […] wrote:
>> Your application is badly designed if it relies on a “beforeunload” event
>> listener triggering a synchronously-handled HTTP request.
>
> on the little red X in the top corner of the window.
No, you have to change the design of your application.
Denis McMahon
Apr 6, 2015, 2:36:59 PM4/6/15
to
On Mon, 06 Apr 2015 18:26:57 +0000, Tim Streater wrote:
> Gee, I'll have to smack those users harder, then, so they don't click on
> the little red X in the top corner of the window.
I guess that technically what you should do is redesign the browser UI
> Gee, I'll have to smack those users harder, then, so they don't click on
> the little red X in the top corner of the window.
component and the back end so that the back end data is never in an
inconsistent state .....
I know, it's a lot easier said than done.
--
Denis McMahon, denismf...@gmail.com
Message has been deleted
Christoph M. Becker
Apr 6, 2015, 5:33:44 PM4/6/15
to
Tim Streater wrote:
> In article <mfujmf$qns$3...@dont-email.me>, Denis McMahon
> That would mean, for instance, that if (as I do) I have a data entry
> area into which the user has typed a load of stuff, and I want them not
> to lose that if they close the window, I'd have to be more or less
> sending every keystroke to the backend. Remember, once they click on
> the little red +, the window is going away whether I like it or not.
>
> Personally I prefer a more pragmatic approach.
A simple solution would be to use the beforeunload event to signal to
the user that there are unsaved changes, giving him/her the chance to
stay on the page (i.e. this document), and to save the changes if desired.
--
Christoph M. Becker
> In article <mfujmf$qns$3...@dont-email.me>, Denis McMahon
> area into which the user has typed a load of stuff, and I want them not
> to lose that if they close the window, I'd have to be more or less
> sending every keystroke to the backend. Remember, once they click on
> the little red +, the window is going away whether I like it or not.
>
> Personally I prefer a more pragmatic approach.
A simple solution would be to use the beforeunload event to signal to
the user that there are unsaved changes, giving him/her the chance to
stay on the page (i.e. this document), and to save the changes if desired.
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Apr 6, 2015, 7:09:50 PM4/6/15
to
Christoph has already made a good suggestion. There are other possibilities
to not having to use the *user-unfriendly* synchronous XHR, but they depend
on the use-case. For example, if you wanted to make sure that a user is
logged out, you could keep a server-side session alive in the background
(using asynchronous XHR if possible, an image or a reloading hidden frame if
necessary) and end it automagically when there is no further request (by
short session lifetime). And on the client-side, you can use a session
cookie or Session Storage.
It should also be noted that Firefox/Gecko is unique in its behavior of
purportedly trying to be “user-friendly”. This can have unforeseen
consequences. For example, there is no good reason why I should not be able
to play an HTML5 audio element from a timeout, why I should get the
following warning instead if I first wanted to play the sound, then invoke
the function:
| Request for full-screen was denied because Element.mozRequestFullScreen()
| was not called from inside a short running user-generated event handler.
Thomas 'PointedEars' Lahn
Apr 6, 2015, 7:15:25 PM4/6/15
to
Appeal to ridicule.
Christoph has already made a good suggestion. There are other possibilities
to not having to use the *user-unfriendly* synchronous XHR, but they depend
on the use-case. For example, if you wanted to make sure that a user is
logged out, you could keep a server-side session alive in the background
(using asynchronous XHR if possible, an image or a reloading hidden frame if
necessary) and end it automagically when there is no further request (by
short session lifetime). And on the client-side, you can use a session
cookie or Session Storage.
It should also be noted that Firefox/Gecko is unique in its behavior of
purportedly trying to be “user-friendly”. This can have unforeseen
consequences. For example, there is no good reason why I should not be able
to request fullscreen mode from a timeout, why I should get the following
Christoph has already made a good suggestion. There are other possibilities
to not having to use the *user-unfriendly* synchronous XHR, but they depend
on the use-case. For example, if you wanted to make sure that a user is
logged out, you could keep a server-side session alive in the background
(using asynchronous XHR if possible, an image or a reloading hidden frame if
necessary) and end it automagically when there is no further request (by
short session lifetime). And on the client-side, you can use a session
cookie or Session Storage.
It should also be noted that Firefox/Gecko is unique in its behavior of
purportedly trying to be “user-friendly”. This can have unforeseen
consequences. For example, there is no good reason why I should not be able
warning instead if I first wanted to play a sound from a HTML5 audio
element, then request full-screen:
| Request for full-screen was denied because Element.mozRequestFullScreen()
| was not called from inside a short running user-generated event handler.
Silvio
Apr 7, 2015, 3:16:40 AM4/7/15
to
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
>
> 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.
>
feature is benign and it expresses at least the desire to remove the
feature at some point.
>
> I do not see your point. Why exactly can that not be done in a user-
> friendly, non-blocking, asychronous way?
>
window.alert from asynch response handler code (i.e. not user initiated)
to be a 'popup' and will block it by default. That is far from
user-friendly. If the synchronous request is part of user initiated code
then the code handling the response is still user initiated and does not
suffer from this disadvantage.
The notion that a synchronous request on its own is not user-friendly is
nonsense. That is only the case if it takes long to complete. That is
something the programmer can make so unlikely a user is not affected.
>
> It has been the standing recommendation for several years now, here and
> elsewhere.
>
people echoing what some browser devs once yelled.
Forcing a sufficiently short (user configurable) timeout on a
synchronous request would be easy to do and would only break cases that
are indeed not user friendly.
No limit is imposed on how long event handling code may run but when it
does a synchronous event then that is considered bad. I see a lot of
crummy web pages that behave hostile towards users by means of embedded
JS. Hardly ever are synchronous requests the culprit.
Thomas 'PointedEars' Lahn
Apr 7, 2015, 6:53:30 AM4/7/15
to
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.
> 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
> and it expresses at least the desire to remove the feature at some point.
deprecated.
>> I do not see your point. Why exactly can that not be done in a user-
>> friendly, non-blocking, asychronous way?
>
> Chrome, Safari, IE and Firefox all consider a window.open or
> window.alert from asynch response handler code (i.e. not user initiated)
> to be a 'popup' and will block it by default.
> That is far from user-friendly.
> If the synchronous request is part of user initiated code then the code
> handling the response is still user initiated and does not suffer from
> this disadvantage.
>
> The notion that a synchronous request on its own is not user-friendly is
> nonsense. That is only the case if it takes long to complete. That is
> something the programmer can make so unlikely a user is not affected.
>> It has been the standing recommendation for several years now, here and
>> elsewhere.
>
> I know
> but I have never seen good arguments for the recommendation, only
> people echoing what some browser devs once yelled.
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.
> Forcing a sufficiently short (user configurable) timeout on a
> synchronous request would be easy to do and would only break cases that
> are indeed not user friendly.
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?
> No limit is imposed on how long event handling code may run but when it
> does a synchronous event then that is considered bad. I see a lot of
> crummy web pages that behave hostile towards users by means of embedded
> JS. Hardly ever are synchronous requests the culprit.
Silvio
Apr 7, 2015, 8:56:02 AM4/7/15
to
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
> 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.
>
the potential problem is real.
>
> *Popups* are not user-friendly, which is why they are blocked by default.
>
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.
>
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.
>
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?
>
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.
>
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.
Message has been deleted
Thomas 'PointedEars' Lahn
Apr 7, 2015, 9:39:45 AM4/7/15
to
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
> 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.
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.
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.
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.
*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.
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.
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.
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
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.
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.
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 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.
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.
Silvio
Apr 7, 2015, 10:54:02 AM4/7/15
to
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
>
> *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.
>
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.
Message has been deleted
Silvio
Apr 7, 2015, 11:42:00 AM4/7/15
to
On 04/07/2015 04:23 PM, Tim Streater wrote:
> In article <5523d3ad$0$2946$e4fe...@news.xs4all.nl>, Silvio
> 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.
> In article <5523d3ad$0$2946$e4fe...@news.xs4all.nl>, Silvio
> <sil...@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.
>
>> 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.
>
>
>>> 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
>>> 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.
>
> 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.
Silvio
Apr 7, 2015, 11:47:45 AM4/7/15
to
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.
>
> 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.
Robert Zeurunkl
Jun 22, 2022, 7:44:48 PM6/22/22
to
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.
The Doctor
Jun 22, 2022, 8:27:49 PM6/22/22
to
In article <9585d114-082a-49b0...@googlegroups.com>,
>
>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
Robert Zeurunkl <bzeu...@gmail.com> wrote:
>
>Google seems to think that all software HAS a user interface. Or even a user.
Is Google that stupid?
>
>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.
>
--
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
Jan Bruns
Jun 23, 2022, 4:46:40 AM6/23/22
to
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
>>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.
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
Scott Sauyet
Jun 24, 2022, 10:44:07 AM6/24/22
to
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
> 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.
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
Arno Welzel
Jun 25, 2022, 6:07:06 AM6/25/22
to
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
> 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.
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
Michael Haufe (TNO)
Jun 25, 2022, 12:47:50 PM6/25/22
to
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:
> What kind of *browsers* don't have a user interface?
<https://en.wikipedia.org/wiki/Headless_browser>
Arno Welzel
Jun 25, 2022, 6:47:44 PM6/25/22
to
Michael Haufe (TNO):
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?
many applications use headless browsers *and* need to use XMLHttpRequest?
Michael Haufe (TNO)
Jun 26, 2022, 12:38:11 PM6/26/22
to
"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.
Arno Welzel
Jun 26, 2022, 1:02:27 PM6/26/22
to
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
> 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"
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.
Michael Haufe (TNO)
Jun 26, 2022, 6:38:16 PM6/26/22
to
On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):
> 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.
> >
> > "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?
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.
Arno Welzel
Jun 27, 2022, 3:32:04 AM6/27/22
to
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?
> 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?
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.
The Natural Philosopher
Jun 27, 2022, 12:49:31 PM6/27/22
to
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
> 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
The Natural Philosopher
Jun 27, 2022, 12:50:03 PM6/27/22
to
Arno Welzel
Jun 28, 2022, 3:40:28 AM6/28/22
to
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".
> On 25/06/2022 11:06, Arno Welzel wrote:
>> What kind of*browsers* don't have a user interface?
>
> Lib curl?
requests and process the response is a "browser".
Arno Welzel
Jun 28, 2022, 3:41:59 AM6/28/22
to
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?
> 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...
The Natural Philosopher
Jun 28, 2022, 6:48:59 AM6/28/22
to
On 28/06/2022 08:40, Arno Welzel wrote:
> 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".
>
>
Semantics.
> 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".
>
>
--
“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
The Natural Philosopher
Jun 28, 2022, 6:59:10 AM6/28/22
to
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.
Arno Welzel
Jun 28, 2022, 9:20:00 AM6/28/22
to
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.
> 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.
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
Jun 28, 2022, 9:20:21 AM6/28/22
to
The Natural Philosopher:
> On 28/06/2022 08:40, Arno Welzel wrote:
>> 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".
>>
>>
> Semantics.
No, facts. curl is not a browser. This has nothing to do with semantics.
> On 28/06/2022 08:40, Arno Welzel wrote:
>> 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".
>>
>>
> Semantics.
John Harris
Jun 28, 2022, 1:27:21 PM6/28/22
to
On 28/06/2022 11:59, The Natural Philosopher wrote:
<snip>
that inspires confidence in others.
John
<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
> simply that it works to do the intended job. I am just an engineer.
that inspires confidence in others.
John
The Natural Philosopher
Jun 28, 2022, 1:42:46 PM6/28/22
to
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.
Michael Haufe (TNO)
Jun 28, 2022, 1:49:00 PM6/28/22
to
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
> 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?
0 new messages