Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cycle.js – A functional and reactive JavaScript framework for predictable code

cycle.js.org

Post reply on HN
Print view View original

41–50 of 64 posts

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#41

Post by bsimpson »

The core idea of Cycle is that the user is a function that reads views and emits user input events; while the application is a function that reads user input events and emits views. (Hence, the name "cycle.")

I thought it was written up in their docs, but this video is what comes up when I search for "user is a function":

https://www.youtube.com/watch?v=1zj7M1LnJV4

This framing, that user input and interfaces react to changes in each other, is a nice way to think about interaction design.

Ergonomically, I find virtual DOM composition in Cycle a bit too cumbersome. Stateless components are just functions that return virtual DOM, but stateful ones need the input/output streams woven in. In practice, this means you end up doing a lot of

const statefulComponent1$ = // compose input streams here

return {

  DOM: combineLatest([

    statefulComponent1$, 

    statefulComponent2$

  ]).map(

    ([ partial1, partial2 ]) => (

      

        { partial1 }

        // ...

      

    )

  )
}

To add state to a stateless component, you've got to do a bunch of refactoring to both the component and its callsite. Instead of passing props/function arguments inline to a stateless component, now you've got to make a variable to hold your stream, pass it into combineLatest, and put a slot in your returned virtual DOM to hold its latest emission. I understand why it's this way, but I also don't like having to think about if a component has state when I'm just trying to use it.

Cycle is a nice architecture for Chrome extensions though. They do a lot of message passing between JS contexts. Because everything in Cycle is a stream, you can wrap the extension messaging API in a stream, and your extension architecture looks like any other Cycle project:

https://github.com/appsforartists/midicast/blob/develop/pack...

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#43

Post by pickle-ts »

staltz wrote: post #38
pickle-ts wrote: post #35

I've used cycle.js on a small commercial project. I'm drawn to novel non-mainstream approaches, and am happy to put up with teething pains with new technology. However, my experience with cycle.js was such that I couldn't recommend the framework to others. Central to the understanding of cycle.js is the concept of observables. An observable is powerful abstraction, as it allows event streams to be programmable. Howev…

I suppose you were using Cycle.js before Cycle State was released. There are a few other projects in production like yours, some of them successfully applying the framework, and others that found difficulties with state management and wiring between components. For anyone out there looking to evaluate Cycle.js for production, I recommend looking at the source code of an open source app I'm actively building: https://…

I suppose you were using Cycle.js before Cycle State was released

No, I was using cycle state/onionify.

[cycle-js] is not a competitor to React

That's not the impression you give in this article: https://staltz.com/some-problems-with-react-redux.html

React may be superior in ecosystem, or with feature coverage, but not so as a paradigm [compared to cycle-js]... Once you learn Elm or Cycle, getting things done will be more productive, less indirect, less verbose, more organized.

Am I quoting you fairly? Have you changed your position?

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#44

Post by jakelazaroff »

xrd wrote: post #28

The thing that got me excited about React was (and please correct me if my vocabulary is incorrect) the virtual Dom and the algorithm to detect changes and only update the dom that changes. Does Cycle.js save that same work and reduce bugs, or is there a hidden cost without that kind of feature? To be specific, this reference criticises setState because it does a bunch of implicit updates to subcomponents. I've seen…

Cycle uses a virtual DOM as well. The difference is that React will call your component functions every time it needs to render, while Cycle will (mostly) only call them once, when the app starts up. A Cycle app is a data flow graph set up by your component functions, with a "driver" at the root observing that data flow and causing side effects, like rendering your virtual DOM or making HTTP requests.

In short: instead of a component being called with props and state and returning VDOM, in Cycle it "maps" a stream of state into a stream of VDOM.

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#45

Post by pickle-ts »

staltz wrote: post #39
Tade0 wrote: post #37

Earlier quoted context omitted.

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 es…

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 interface with the GWT (Google Web Toolkit) AsyncCallBack interface to create the pair of interfaces IObservable and IObserver that model asynchronous data streams with values of type T.

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#46

Post by tanilama »

pickle-ts wrote: post #35

I've used cycle.js on a small commercial project. I'm drawn to novel non-mainstream approaches, and am happy to put up with teething pains with new technology. However, my experience with cycle.js was such that I couldn't recommend the framework to others. Central to the understanding of cycle.js is the concept of observables. An observable is powerful abstraction, as it allows event streams to be programmable. Howev…

Mobx does just that

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#47

Post by [deleted] »

lilactown wrote: post #32
vemv wrote: post #25

Earlier quoted context omitted.

That's super interesting. Imagine that as a cljs developer, Cycle and re-frame were exactly as easy to use (i.e., skip the fact that Cycle is written in a different language). In that case which one would you prefer / why?

The sticks I would use to measure a framework like Cycle and re-frame are: 1. How well does it compose? 2. How simple are the tools? Both re-frame and Cycle have their issues with composition. Cycle has inherent complexity and difficulty with composing dynamic child-states and circular dependencies as outlined above. It sounds like there have been tools developed since I last used Cycle.js to ameliorate the difficult…

[deleted]

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#48

Post by staltz »

pickle-ts wrote: post #45
staltz wrote: post #39

Earlier quoted context omitted.

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 a…

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.

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#49

Post by staltz »

pickle-ts wrote: post #43
staltz wrote: post #38

Earlier quoted context omitted.

I suppose you were using Cycle.js before Cycle State was released. There are a few other projects in production like yours, some of them successfully applying the framework, and others that found difficulties with state management and wiring between components. For anyone out there looking to evaluate Cycle.js for production, I recommend looking at the source code of an open source app I'm actively building: https://…

I suppose you were using Cycle.js before Cycle State was released No, I was using cycle state/onionify. [cycle-js] is not a competitor to React That's not the impression you give in this article: https://staltz.com/some-problems-with-react-redux.html React may be superior in ecosystem, or with feature coverage, but not so as a paradigm [compared to cycle-js]... Once you learn Elm or Cycle, getting things done will be…

That article was written many months/years before Cycle-React interop was built. I still maintain some of those positions because of Redux, but when you take React without Redux, it's just a rendering library, and as such could be theoretically used with Cycle.js. Now that React has good APIs like Context, ForwardRef, and function components, the interop with Cycle.js is easy and well done.

Re: Cycle.js – A functional and reactive JavaScript framework for predictable code

#50

Post by pickle-ts »

staltz wrote: post #48
pickle-ts wrote: post #45

Earlier quoted context omitted.

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 a…

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…

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.
Post reply on HN