W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: =[xhr]

From: Olli Pettay <olli@pettay.fi>
Date: Fri, 25 Jul 2014 15:26:49 +0300
Message-ID: <53D24D09.3010002@pettay.fi>
To: public-webapps@w3.org
On 07/24/2014 02:49 AM, Paul bellamy wrote:
> Hi
>
> In the specification for XMLHttpRequest you posted a “warning” about using async=false which indicates that it is the intention to eventually remove
> this feature due to “detrimental effects to the user experience” when in a document environment.
>
> I understand that synchronous events retrieving data can, if not managed properly in the code, cause delays to the flow of the parsing and display of
> the document.

Sync XHR does always cause jank, and one can't really control how bad, since it depends on the quality of the network.
See for example http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx



> This may, if the programming practices are poor, be extrapolated to be “detrimental to the users experience”, however there are times
> when there is a need to have data retrieved and passed synchronously when dealing with applications.
>
> In *business* application development there will always be the situation of the client needing to manipulate the display based on actions that
> retrieve data or on previously retrieved data. In these cases it is necessary for the data retrieval to be synchronous.
Why you need synchronous XHR in this case? Async XHR can be used just as well to retrieve data which is then used for manipulating the UI.

>
> If the document/form has to be resubmitted in full each time a client-side action is taken or the client needs to retrieve data to decide what action
> to take, then the user experience is definitely affected detrimentally as the entire document needs to be uploaded, downloaded, parsed and displayed
> again. Further there is the unnecessary need to retain instances of variables describing the client-side environment on the server-side.  Variables
> which are not necessary for processing and should be handled by the client.
>
> For this reason I wonder why it would be necessary to remove such a useful tool.
>
> I don’t claim to be the expert on programming or technical specification, perhaps I’ve missed something in the specification and I am more than happy
> to be shown better ways to manage the development of our business applications.  It just seems to me that deciding the user’s experience is
> detrimentally affected by the possibility of some developers having poor programming practices
Using synchronous calls in the UI thread is a bad practice.


-Olli


> seems to be a fairly blinkered approach to the
> development process of such fantastic tools as XMLHttpRequest .
>
> I would welcome discussion or advice on this topic .
>
> Thanks for your time in reading this
>
> Paul Bellamy
>
> (Director)
>
> */Pacific West Data Pty Ltd/*
>
> /Ph:/ +61-412-754-052
>
> www.pacificwestdata.com <http://www.pacificwestdata.com/>
>
Received on Friday, 25 July 2014 12:28:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC