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

11–20 of 64 posts

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

#11

Post by staltz »

jakelazaroff wrote: post #2

Cycle is really cool, and I'd love to see reactive programming become more popular, but after trying it out for a project it has a few ergonomics issues that keep me from using it as my primary web framework. - Dynamic lists of components are really annoying to create. In Cycle, the happy path is calling every component function in your app at startup to set up the data flow graph, and then your reactive operators ha…

I totally agree with the two issues you listed! I think both of them are well enough addressed with Cycle State, a new state management library. It has an API makeCollection() specifically meant for dynamic lists, with good DX and great performance. Also I regret imitate(), and gladly using Cycle State I haven't found a single need anymore for imitate().

Not mentioned in the official docs (yet), but Cycle.js has nowadays full support for React DOM and React Native.

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

#13

Post by staltz »

staltz wrote: post #11
jakelazaroff wrote: post #2

Cycle is really cool, and I'd love to see reactive programming become more popular, but after trying it out for a project it has a few ergonomics issues that keep me from using it as my primary web framework. - Dynamic lists of components are really annoying to create. In Cycle, the happy path is calling every component function in your app at startup to set up the data flow graph, and then your reactive operators ha…

I totally agree with the two issues you listed! I think both of them are well enough addressed with Cycle State, a new state management library. It has an API makeCollection() specifically meant for dynamic lists, with good DX and great performance. Also I regret imitate(), and gladly using Cycle State I haven't found a single need anymore for imitate(). Not mentioned in the official docs (yet), but Cycle.js has nowa…

Sorry, forgot to link:

https://github.com/cyclejs/react

https://github.com/cyclejs/react-dom

https://github.com/cyclejs/react-native

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

#14

Post by wild_preference »

todd3834 wrote: post #10
awaisraad wrote: post #9

Man, I should start pasting my bookmarks on HN - that will give major boost to my HN score.

Please do, why not?

They were being dismissive, suggesting that this is old news and something they already had on vinyl. As if all we care about is the new shiny and can't possibly be interested in nor discuss existing things.

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

#15

Post by _uhtu »

sritchie wrote: post #7
typon wrote: post #5

Earlier quoted context omitted.

What makes you guess that `name$` is a boolean?

I think the poster is assuming that .startWith(“) returns a Boolean, yeah?

startWith, in this context of streams, means "let this value (in this case an empty string) be the first value the stream returns"

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

#17

Post by apolymath »

I am definitely an advocate for reactive programming, as I have used React Native to develop a cross-platform mobile application (https://dedicate.datasilk.io), but when it comes to web development, I am very much an advocate for using the basic tools that were given to us web developers to build web applications.

These tools include mainly HTML & CSS, and when needed, "vanilla" JavaScript (and maybe even a compact jQuery alternative like zepto), but in no way do I advocate for using client-side frameworks for developing web applications. It is because they are difficult to debug, sometimes near impossible, and also because it leads the developer astray from practicing basic concepts such as writing beautifully formatted HTML & CSS or utilizing small bits of JavaScript for event handling & AJAX calls. Instead, they are forced to focus nearly all of their attention to writing JavaScript in what I call a "black box" environment where they send input into the black box and the magical sorcery of said black box somehow outputs a graphical user interface.

A web application should harness the power of the web browser's native capabilities instead of harnessing the powers of a JavaScript framework, because the web is a beautiful place made of beautiful technologies that were built in the golden era of technological creativity. Because of such creativity, many great people came together and invented HTML, CSS, and JavaScript, the near-perfect solution to a very complex, graphically interactive problem.

Sure, you may think that you want to build a single-page application, and that's fine. Why not test your skills and write a micro-library that harnesses the HTML5 History API along with a simple AJAX method to transform your website into that single-page app you fantasize about daily.

Sure, you may think using the JavaScript "import" keyword in all of your many JavaScript files is okay because it's a single-page app that you're building and all those thirty-some-odd JS files will only be loaded one time for each user session when the app initializes, but what you don't understand is that you are lazy and careless and on a daily basis, you make excuses for all of your sins.

You and I both know that your application only needs ONE small JS file on initialization and ONE dynamically loaded JS file for each area within the app that your user may or may not navigate to in the first place.

So, for the love of all humanity, please, please, write HTML & CSS, and pepper it ever-so-lightly with bits of JavaScript (but only when it is absolutely necessary).

If you need a more convincing argument to steer away from client-side JavaScript frameworks, simply read this small comic strip: https://xkcd.com/927/

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

#19

Post by shados »

XCSme wrote: post #4

The code looks a bit messy to be honest, maybe it's just the variable naming. `const input$ = sources.DOM.select('.field').events('input')` Why not name it the same as the DOM function `querySelector` ? `const name$ = input$.map(ev => ev.target.value).startWith('')` Wouldn't in this case `name$` be a boolean, but then `map` is called on a boolean. I just find the syntax very confusing.

The conventions, naming, etc are not Cycle (or even JavaScript, in most case) specific. It's just straight out of the reactive programming ecosystem.

I think Cycle uses XStream these days, assuming it didn't change again from last time I looked, and they renamed some stuff from the previous RxJS based implementation to be a bit friendlier, but even then the streams are not necessarily about DOM/html. CycleJS lets you do everything with streams, from managing http request or I/O and any other form of environment input. And yes, that includes DOM events, but it wouldn't make sense to name functions in a general API after a specific use case.

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

#20

Post by lilactown »

lgessler wrote: post #3

Can anyone comment on how Cycle.js compares to other frontend FRP frameworks like ClojureScript's re-frame[1]? [1]: https://github.com/Day8/re-frame

[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 tied together in your "main" function.

Cycle.js requires you to reason about, write and read your application code in terms of reactive "streams" of values. This means that a big part of your app's development is expressing it in terms of operations on reactive streams and using the language of whichever stream library you choose.

Re-frame favors separating your UI code (which you can compose) from state and other side effects (which are global) through it's use of named reactive subscriptions and dispatching of named events.

You register your app's events as functions that take in "coeffects" (e.g. the current state of your app) and returns "effects" as data, e.g. the new state of your application. You can also return other "effects" like the parameters for doing an HTTP request and what event to dispatch when it completes/fails. Your UI code is then written to dispatch the names of these events (e.g. on click) that will trigger the registered function and cause re-frame to run the returned effects.

You register your app's subscriptions as functions that take in the application state and return a materialized view of it. Your UI code is then written as functions that subscribe to the names of these subscriptions, take the materialized view of your app state and return the UI tree that should be shown.

The majority of your re-frame app code is written as regular functions which return data. This means that a big part of your app's development is expressing it in the terms of functions that return data so that the UI framework (React/reagent) can render it and re-frame can do the appropriate side effects.

Cycle.js is a very "pure" framework, in that it's approach is to start from first principles - pure functions, application-as-a-stream - and to layer on tools and abstractions to make it effective. The work that the core of Cycle.js actually does for you is quite minimal, and the skeleton and muscles of your application is not at all hidden from you.

Re-frame is much less "pure"; it has a guiding concept of separating your UI code from the side effects it produces. For instance, many UI functions are not pure because they subscribe to the global app state. And in fact you don't have to use re-frame for everything at all; you can opt to use local component state and direct mutation instead of that fits your use case better.

Post reply on HN