I second Gregg's suggestion. It should be up to the developer to decide
whether he wants to block or not.

On 02/05/2015 08:58 PM, Gregg Tracton wrote:
> I disagree with deprecating synchronous XMLHttpRequest:
> 1) it is not upward compatible & so can break numerous sites.
> Many websites do not have active development, and framework updates
> that fix this are even slower to roll out to web apps.  Many web
> app clients would much prefer a sub-optimal experience than a
> broken website.
> 2) A better way to approach this might be to respect the async=false
> setting but have the browser move the script thread to another thread which
> is blocked until the jax (not ajax anymore) completes.  Make the browser do
> the heavy lifting so scripts remain simple.
> 3) Loading long chains of on-demand content becomes unnecessarily complex.
> Example: a config file that specifies URLs for column headers which specify
>  URLs for content requires 3 nested .success handlers.  With async=false,
>  one can simple write those sequentially.
> 4) Have it been considered if jQuery can create a work-around to simulate
> async=false?  If not, do not deprecate, as there will be even more
> browser-specific code splintering.
> 5) When data loads slowly, many sites will show a "please wait"
> view anyway, which disables useful interactions, so how much value
> does this deprecation add to usability?
> 6) Do you really want script writers to deal with scroll events while
> an ajax is outstanding?  That seems to be beyond the ability of a plug-in
> to handle in the general case. async=false really simplifies some tasks.
> --Gregg Tracton, Chapel Hill, NC, USA

Reply via email to