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

31–40 of 64 posts

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

#31

Post by kylecordes »

Cycle is very interesting, and Andre is a genius. Even if you will never use Cycle in "real work", learning it enough to build anything at all will enhance your understanding of many things. Particularly around reactivity and state.

A while back I dug in enough to make a short series of videos explaining how some simple Cycle apps work. They are not up to date with the Cycle progress since then, but nonetheless are probably still a decent way to get a sense of what Cycle is like.

https://www.youtube.com/watch?v=DEHgcT_RmJc&list=PLP4qxCldB2...

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

#32

Post by lilactown »

vemv wrote: post #25
lilactown wrote: post #20

Earlier quoted context omitted.

[NOTE: I have much more experience using re-frame than Cycle.js, but have used both previously] Cycle.js and re-frame, in some ways, are on opposite sides of various spectrums. Cycle.js favors local reasoning and composability through modeling your application as a pure function that takes in streams (sources) and returns streams (sinks). All of your event handling, external data, DOM changes, etc. are explicitly tie…

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 difficulties in handling these cases.

Re-frame has complexity with composition because it uses an absolute global namespace, which makes multi-tenant scenarios very awkward and potentially insecure. This problem mainly exists in use cases like having a developer environment with multiple states of the application on the same page, consuming components developed by external teams, and server-side rendering. At the moment these are either worked around or avoided completely.

The simplicity of the tools is something that I am very passionate about. As someone infected by the Clojure virus, I am pretty excited about the ability to use regular functions that return data to build my applications. It has been several years since I went down the rabbit hole of "everything as a stream/observable." At the time I found it to be very intellectually exciting, but also very confusing. Functions and data are much more familiar tools to most developers and the ergonomics of designing, developing, and debugging functions and data are much more understood.

So in closing, I would choose re-frame over Cycle for a project that I was working with a team of developers on. For extremely large applications that needed to be developed cross-team and/or have a strong use-case for server-side rendering... I would probably pick something new- similar to re-frame, but which fixes it's issues with composition. I maaayyyyy be working on something like that. ;)

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

#33

Post by aarpmcgee »

jakelazaroff wrote: post #27
aarpmcgee wrote: post #22

Earlier quoted context omitted.

Is there JSX support?

Yup! https://cycle.js.org/getting-started.html#getting-started-co... If you're just starting out though (or even if you're not) I'd recommend checking out create-cycle-app, the Cycle analogue to create-cycle-app that will set up things like that for you: https://github.com/cyclejs-community/create-cycle-app

Rad! Thanks!

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

#35

Post by pickle-ts »

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. However, an overreached abstraction can be even worse than a lack of abstraction. Cycle.js gratuitously applies the observable abstraction to its component model.

The cycle.js notion of a component is a object that takes multiple observable sources, and emits multiple observable sinks. I have to admit, at first I didn't see this as problematic: to the contrary - it actually struck me as elegant. What I didn't realize, before building a real-world project with cycle, was that this meant all interactions between components were asynchronous. So each component cannot even access the state of another component without communication via observables. This introduces enormous needless complexity into an application. Not only do you have to pay an up front mandatory boilerplate tax to minimally wire together your components, you'll tie yourself in knots readjusting that wiring to get those components to communicate with each other in the way you need.

We actually ended up re-writing the project with our own framework, pickle: https://github.com/pickle-ts/pickle For us, this substantially increased maintainability / reduced the code size of our application compared with cycle.js, or the prototype we wrote with react/redux. The code reduction came from realizing the appropriate abstraction: the entire application should be composed of an object-oriented hierarchy of stateful components, where on each update, these mutable components render themselves as immutable v-dom trees. Anyway, to counteract any pluggishness (our framework is obviously super new so is only of interest to ultra early-adopters), the conservative sensible choice for a web framework right now is to use react or vue /w a state manager. Not cycle.js.

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

#36

Post by JSDave »

"const input$ = sources.DOM.select('.field').events('input')"

Is there a switchMap in here?

What happens if the input element is removed/inserted back into the DOM?

"input('.field', {attrs: {type: 'text'}}),"

It's possible right now for the value in this input to differ from the value in input$.

Maybe use a combineLatest and then this?

"input('.field', {attrs: {type: 'text', value: inputVal}}),"

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

#37

Post by Tade0 »

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…

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 especially expensive.

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

#38

Post by staltz »

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://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.

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

#39

Post by staltz »

Tade0 wrote: post #37
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…

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.

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

#40

Post by z3t4 »

gcb0 wrote: post #29
ww520 wrote: post #18

This looks not much different than the usual way of doing event binding and rendering in the event callback.

lol. yes. maybe the name means full-circle :)

Give it a few more years and we'll see .ondblclick and event listeners.
Post reply on HN