Why I chose to use Cycle.js
Vincent O

“You end up having to use built in helpers like componentWillMount, this.state, this.props, componentDidMount” — ok, this sounds like you don’t really understand that there are some constraints when using a framework; why don’t you feel the same way about the 200+ functions that rx has?

“There is nothing bad about that but I was after more flexibility.” — how can you define “more flexibility”?

“… I want a non intrusive framework, one that has a simple dataflow concept, still learning JavaScript skills that will outlive the framework” — at this point, i began to think you’re whining. Every javascript framework out there, can teach you lots of things — mvvm, mvp, mvc, mv*, IoC(angular), unidirectional dataflow(react), domain modeling(backbone model), etc

“You’re no longer learning a framework but very useful tools and concepts which you can take away with you!” — so basically you’re telling me that by learning de unidirectional dataflow w/e of flux or the more newer and more powerful redux, i won’t be able to take this with me and apply these concepts elsewhere?

Ok, enough bashing, for now.

I’m not a troll nor the best dev(i wish to become) but this article, to me, has ZERO value. It didn’t taught anything new-neither cyclejs nor rx(though i’m pretty familiar with rx, using it in some projects). You haven’t presented anything new(cyclejs is out there for some time). You haven’t presented anythin that has a real value. Instead, you bashed many concepts you haven’t really tried to understand — every framework has lifecycle methods(see cocoa, react native, ember, backbone, angular, etc) and every framework has constraints(even rx*).


Like what you read? Give Dragos Tudorache a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.