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
>
>
>
>