Async xhr with callback let's you manage the flow such that you don't do 
anything until a successful response from the server. Promises make it even 

Sent from my iPhone

> On Feb 10, 2015, at 9:15 AM, George Calvert <> 
> wrote:
> Ashley,
> Isn't it for the app dev team — rather than the standards body or even the 
> browser team — to decide whether the UI thread should wait on the server?
> I see it like this: The user, with the app as middleman, is conversing with 
> the server.  Just as we want modal dialogs because sometimes it makes sense 
> to say "Answer this before proceeding", sometimes we want a synchronous call 
> in the main thread (because we want an answer from the server before 
> proceeding).
> Sure, I can present a dialog as non-modal — but then I've got to manage the 
> loose-ends if left unfinished.  Maybe I can toss all that into a cookie — and 
> maybe I can't.  Having a modal dialog as an option allows us to simplify the 
> code and avoid a lot of what-happened-to-my-data calls to the help desk.
> For me, it's the same with calls to the server.  Common use-cases are log-in 
> and master/parent-object creates.   In my apps, the UI depends on 
> user-specific config that is returned upon log-in.  As well, there are 
> instances where creating a parent object precedes creating child objects and 
> it just creates a dozen headaches to let the user proceed without 
> confirmation that the parent exists server-side.
> I agree the goal is to model as much as possible as asynchronous.  My issue 
> is that there are still real-world, practical applications for S-JAX and that 
> identifying those is the app developer's job, not W3C's.
> Heck, why not go the other way and deprecate AJAX now that web workers make 
> background threads a first-class object available for any processing?  ;-)
> Best,
> George

Reply via email to