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 nicer.
Sent from my iPhone > On Feb 10, 2015, at 9:15 AM, George Calvert <george.calv...@loudthink.com> > 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 > > >
