4 ms·

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 th

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 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?

staltz 8y ago
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.
- pickle-ts 8y ago
  FWIW I agree with you I'm not enamoured by react/redux.
  - WorldMaker 8y ago
    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).

staltz 8y ago

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.

pickle-ts 8y ago
FWIW I agree with you I'm not enamoured by react/redux.
- WorldMaker 8y ago
  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).