Hacker News Reader

Comment by Tade0 | Hacker News Reader

What I didn't realize, before building a real-world project with cycle, was that this meant all interactions between components were asynchronous. [...] This introduces enormous needless complexity into an application.

This hits the nail on the head. I spent a year using the author's other project - Rx.js - and while I understand the benefits of using it I don't think they outweigh the costs.

And asynchronicity is especially expensive.

View on HN

Two corrections: RxJS is not my project, I only helped as a contributor (sometimes voluntary; sometimes core). And second: stream chains are not necessarily asynchronous, in fact they are synchronous by default. I don't know what the commenter above meant with that asynchrony comment.

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

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.

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.

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.

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.

Reply on news.ycombinator.com