Re: =[xhr]

2014-08-02 Thread Austin William Wright
On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard wrote:

 On Fri, Aug 1, 2014 at 8:39 AM, wrote:

 Spinner is not sufficient.  All user activity must stop.  They can take
  a coffee break if it takes too long.  Browser must be frozen and locked
 down completely.  No other options are desirable.  All tabs, menus, etc.
 must be frozen.  That is exactly the desired result.

 My browser isn't yours to lock down.  My menus aren't yours to freeze.
  You don't get to halt my browser, it doesn't belong to you.

 In this case, a freeze on all browser operations is desirable.

 It may be desirable to you, but it's never desirable to the user, and
 users come first.

This seems rather cold (I wouldn't presume that the described usage is
actually bad for the users, not having seen the program in question),
though assertion is technically correct (if users are at odds with
development of a technical report, users come first). I would point out:

It may be cheap for the developer to use synchronous mode, but it's not the
UI event loop works, and as such it's almost always a bad proposition for
the user. It's not a sustainable coding pattern (what if you want to listen
for two operations at the same time?), it's generally a hack all around. It
doesn't negate the need for your application to perform sanity checks like
Is the data loaded? Does performing this operation make sense?, even if
using synchronous mode *seems* to let you avoid such checks.

Maybe there's another reason: Good idea or no, removing this feature DOES
break reverse compatibility with the de-facto behavior of many Web
browsers. I'm not sure that's reason enough to standardize on the behavior,
though. However, it may be enough a reason to file a bug report if the
behavior ever breaks (though if they come back and say it was never
standardized behavior to begin with, you shouldn't have been using it in
production, I can't really blame that either).

Austin Wright.

Re: =[xhr]

2014-08-02 Thread David Bruant

Le 02/08/2014 11:11, Austin William Wright a écrit :
Maybe there's another reason: Good idea or no, removing this feature 
DOES break reverse compatibility with the de-facto behavior of many 
Web browsers.
Everyone who wants sync xhr to disappear is well-aware. That's the 
reason it hasn't been removed yet.

Just as a reminder, we live on Planet Earth where the distance between 
two computers who want to communicate with one another can be 20.000km. 
A signal at speed light takes 60ms. But our network isn't either at 
speed light nor in straight line, so the delay is easily multiplied by 
20 and that's very optimistic. And that's just the latency. Bandwidth 
considerations and data processing times aren't free.
On the other hand, we're human beings and notice 100ms delays and all 
evidence converge in the direction of saying that human beings are 
frustrated when they feel a delay, so making people wait is terrible. 
(interesting talk which discusses perceived performance at one point )
Sync xhr forces a delay and there is no way around that, ergo, it's 

I'm probably not old enough to accurately make this comparison, but 
blocking I/O looks like it's 2010-era GOTO. I heard when higher-level 
programming came around, some people were strong defenser of GOTO. Now, 
most people have moved to higher-level constructs.

I think the same fate is waiting for blocking I/O.