> I mean the promises-unwrapping proposal that has now been accepted into 
> ES6 and the DOM, and IIUC is being implemented by several browser makers. 
> Let's call these JS Promises. 

The unwrapping means that there is forced recursive synchronization,
doesn't it? When trying to work with nested promises, implicit unwrapping
leaves a single level of asynchrony, assuming synchrony beyond that.

> * One cannot ignore network latency and partitioning.
> 
> Latency:
> JS Promises are asynchronous and were carefully designed to not preclude
> future promise pipelining. Q makes use of this pipelining.
> 
> * Sync RPC is the wrong model (it already yielded to async calls,
> futures/promises, and the like).
> 
> Exactly!

And yet JS promises ended up with a synchronous model behind a 
single layer of asynchronous access. Only the maximal latency is
explicit, with async interface, any nested layers of access are implicit,
with sync interface.

Claus

> I mean the promises-unwrapping proposal that has now been accepted into 
> ES6 and the DOM, and IIUC is being implemented by several browser makers. 
> Let's call these JS Promises. 

The unwrapping means that there is forced recursive synchronization,
doesn't it? When trying to work with nested promises, implicit unwrapping
leaves a single level of asynchrony, assuming synchrony beyond that.

>> * One cannot ignore network latency and partitioning.
> 
> Latency:
> JS Promises are asynchronous and were carefully designed to not preclude
> future promise pipelining. Q makes use of this pipelining.
> 
>> * Sync RPC is the wrong model (it already yielded to async calls,
> futures/promises, and the like).
> 
> Exactly!

And yet JS promises ended up with a synchronous model behind a 
single layer of asynchronous access. Only the maximal latency is
explicit, with async interface, any nested layers of access are implicit,
with sync interface.