5 ms·

It's misleading to say observables are not asynchronous. The raison d'etre of obserables is to support asynchronous operations, and it's this capability that co

It's misleading to say observables are not asynchronous. The raison d'etre of obserables is to support asynchronous operations, and it's this capability that constrains the programming model. To quote Erik Meijer - the godfather of observables - in this article https://queue.acm.org/detail.cfm?id=2169076 https://queue.acm.org/detail.cfm?id=2169076 There are many ways to derive Rx, some involving category theory and appealing to mathematical duality, but this article shows how every developer could have invented Rx by crossing the standard JDK (Java Development Kit) Future<T> interface with the GWT (Google Web Toolkit) AsyncCallBack<T> interface to create the pair of interfaces IObservable<T> and IObserver<T> that model asynchronous data streams with values of type T.

staltz 8y ago
I didn't say "observables are not asynchronous", I was referring to the comment "interactions between components are asynchronous" which to me sounds like "event emission and propagation". Propagation is often synchronous when using RxJS 6 which uses by default the recursive scheduler, and with xstream, which is similar. For instance, event emissions along the chain a$.map (f).filter(g).take(10) are synchronous. But I suppose the confusion here is what people mean with "asynchronous". To me it means a set of computations that are allowed to happen sparsely, with other computations potentially happening in between. A lot of people assume that callback-driven code in JS is necessarily async (and maybe that's what you meant with the use of the word), but it's common in the JS reactive programming community to recognize that callbacks can also be executed synchronously, for instance array.forEach(cb) is synchronous although it's callback-based and as such could have been asynchronous through the same cb API.
- pickle-ts 8y ago
  Andre - the point is that the inter-component wiring between cycle.js components is verbose and unwieldy due to the asynchronous-capable protocol. Definitions are of course important, but in this case dwelling on them is to side-track a criticism, rather than to address that criticism directly.
- colordrops 8y ago
  With observables, they can be executed synchronously or asynchronously in JS, but it's a bit of a leaky abstraction when you have to be aware of the internals of particular stream operation to known whether it is synchronous or not, so to avoid unnecessary complexity you need to assume asynch behavior for all streams.

staltz 8y ago

I didn't say "observables are not asynchronous", I was referring to the comment "interactions between components are asynchronous" which to me sounds like "event emission and propagation". Propagation is often synchronous when using RxJS 6 which uses by default the recursive scheduler, and with xstream, which is similar. For instance, event emissions along the chain a$.map (f).filter(g).take(10) are synchronous. But I suppose the confusion here is what people mean with "asynchronous". To me it means a set of computations that are allowed to happen sparsely, with other computations potentially happening in between. A lot of people assume that callback-driven code in JS is necessarily async (and maybe that's what you meant with the use of the word), but it's common in the JS reactive programming community to recognize that callbacks can also be executed synchronously, for instance array.forEach(cb) is synchronous although it's callback-based and as such could have been asynchronous through the same cb API.

pickle-ts 8y ago
Andre - the point is that the inter-component wiring between cycle.js components is verbose and unwieldy due to the asynchronous-capable protocol. Definitions are of course important, but in this case dwelling on them is to side-track a criticism, rather than to address that criticism directly.
colordrops 8y ago
With observables, they can be executed synchronously or asynchronously in JS, but it's a bit of a leaky abstraction when you have to be aware of the internals of particular stream operation to known whether it is synchronous or not, so to avoid unnecessary complexity you need to assume asynch behavior for all streams.