3 ms·

Newsflash: Guy who created Cycle.js because he didn't like React thinks Cycle.js is better than React. (He also thinks Elm is better than Redux, but I think h

by Lazare 11y ago

Newsflash: Guy who created Cycle.js because he didn't like React thinks Cycle.js is better than React. (He also thinks Elm is better than Redux, but I think he's significantly overstating the differences between Elm and Redux's patterns, and significantly understating some of the drawback's inherent in the Elm language, as opposed to the Elm patterns. Developers I know who have used Elm for production projects seem to have very mixed feelings about it, and many have since abandoned it for Purescript.) He's probably right about Cycle though, for some devs, on some projects. Then again, I've spoken to people who went all in on Cycle and got burned, and found it inferior to React. A guide to when you might prefer Cycle to Redux would be interesting, but this isn't it. (And as others have noted, his comments about JSX versus hyperscript is quite odd. React is not tied to JSX, and you can easily use hyperscript with React if you choose. It's just that people don't, because most people don't find hyperscript as awesome as he does. Which is sort of the article in a nutshell; "X is better than Y because I like X!")

knite 11y ago
Can you share why and how these Cycle.js users were burned by the framework? I've been considering it for a project and would love to hear about how it's gone wrong for others.
- Lazare 11y ago
  Unfortunately, I can't; it was some idle chatter after a meetup, and I may have had a couple of drinks at the time. :) From memory, it was based around the way the redux patterns is very top down with a single state atom, smart reducers, and dumb components, but the cycle pattern is very bottom up with smart components and no centralization. So as your app gets complicated with cycle, you can start to lose track of all the different streams and start to struggle with figuring out what your app is doing in total. Mind you, they may have just been doing cycle wrong, and you have to take people complaining about their tools with a grain of salt. But the impression I got is that cycle is not a magic bullet that makes large, complicated apps with difficult state management problems easy to code, any more than redux is. Cycle is great when you start looking at redux and go "oh shit, I do NOT want to start coding these reducers, can I just break it down into tiny parts and solve each one on its own", but redux is great when you start looking at cycle and go "oh man, I do NOT want to try and figure out how all these bits work together, can I just put all this crazy logic in one place?" (Disclaimer: Have never used cycle; just talked to some people who have.)
jbergens 11y ago
The jsx part is a bit of saying "X is better than Y because I like X!" but I see the rest of the article as more about why he thinks React+Redux are harder to use. A lot of it has to do with the number of things to learn and functional instead of OO. The last part is a belief held by many developers. I haven't tried Elm or Cycle in production but think our code would be much easier to work with if it were written in any of those that it is today with React. There might be other problems like stability and some special features we might miss or the learning period might be much longerthan I think but overall both alternatives looks better to me.
- mchahn 11y ago
  > I haven't tried Elm or Cycle in production but think our code would be much easier to work with if it were This is yet one more article that makes me want to try Elm. It has been mentioned more and more often here, but I don't know if its actual usage has grown as much.
mercer 11y ago
I really liked the guide for 'x versus y' that Vue.js provided. It was fair, honest, and actually resulted in me choosing React.js for a particular project while simultaneously leaving Vue.js on my radar for other projects. (I vaguely recall Ractive.js doing something similar, which led me to make the opposite choice and use that instead of React.)

by Lazare 11y ago

knite 11y ago

Can you share why and how these Cycle.js users were burned by the framework? I've been considering it for a project and would love to hear about how it's gone wrong for others.

Lazare 11y ago
Unfortunately, I can't; it was some idle chatter after a meetup, and I may have had a couple of drinks at the time. :) From memory, it was based around the way the redux patterns is very top down with a single state atom, smart reducers, and dumb components, but the cycle pattern is very bottom up with smart components and no centralization. So as your app gets complicated with cycle, you can start to lose track of all the different streams and start to struggle with figuring out what your app is doing in total. Mind you, they may have just been doing cycle wrong, and you have to take people complaining about their tools with a grain of salt. But the impression I got is that cycle is not a magic bullet that makes large, complicated apps with difficult state management problems easy to code, any more than redux is. Cycle is great when you start looking at redux and go "oh shit, I do NOT want to start coding these reducers, can I just break it down into tiny parts and solve each one on its own", but redux is great when you start looking at cycle and go "oh man, I do NOT want to try and figure out how all these bits work together, can I just put all this crazy logic in one place?" (Disclaimer: Have never used cycle; just talked to some people who have.)

jbergens 11y ago

The jsx part is a bit of saying "X is better than Y because I like X!" but I see the rest of the article as more about why he thinks React+Redux are harder to use. A lot of it has to do with the number of things to learn and functional instead of OO. The last part is a belief held by many developers. I haven't tried Elm or Cycle in production but think our code would be much easier to work with if it were written in any of those that it is today with React. There might be other problems like stability and some special features we might miss or the learning period might be much longerthan I think but overall both alternatives looks better to me.

mchahn 11y ago
> I haven't tried Elm or Cycle in production but think our code would be much easier to work with if it were This is yet one more article that makes me want to try Elm. It has been mentioned more and more often here, but I don't know if its actual usage has grown as much.

mercer 11y ago

I really liked the guide for 'x versus y' that Vue.js provided. It was fair, honest, and actually resulted in me choosing React.js for a particular project while simultaneously leaving Vue.js on my radar for other projects. (I vaguely recall Ractive.js doing something similar, which led me to make the opposite choice and use that instead of React.)