Hacker News Reader

Comment by staltz | Hacker News Reader

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://github.com/staltz/manyverse I am happy with the architecture, specially how well it manages React Native's many native APIs in a well organized way.

I also need to emphasize that Cycle.js is more of an architectural framework, not much of a rendering framework, so it's not a competitor to React, you can use both together. React for rendering, and Cycle.js for architecture and orchestration.

View on HN

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?

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.

FWIW I agree with you I'm not enamoured by react/redux.

redux-observable has helped me get some of the better parts I liked about Cycle into a more "traditional" React app setup.

For maintainability by other developers I've been migrating my biggest Cycle app into a "traditional" React app. Partly because I got very caught up into some "plumbing" issues in Cycle, with lots of dynamic components and keeping them performative starting being far too much work, especially if I expected other developers to read it, much less touch it. The Cycle/React-interop has gotten better so that I might contemplate React-hosted Cycle components for future needs, but at this point with the vast React ecosystem and increasing Junior Developer-friendliness of "traditional" React, it makes the most sense to just use as much off-the-shelf React as possible and Redux seems familiar to more developers (even if they might not immediately get what redux-observable "epics" are doing).

Reply on news.ycombinator.com