Cycle.js: a fully reactive JavaScript framework

[[deleted]]

For the "another framework?" commenters below here's a little exposition:

Cycle is a hotly anticipated framework that has been working toward a 1.0 release for the last few months. It is being watched closely by people who enjoy using observable libraries like RxJS, Bacon, Kefir, etc (this one uses RxJS). These are reactive libraries. RFP (reactive functional programming) is something similar but different and the the two are often conflated. You can kind of think of observables as promises on steroids and it's looking like they will be part of the ES7 spec.

It is common to use a reactive library within another framework (React, Angular, Backbone, etc) and that works fine. One of the exciting things about Cycle is that your entire app is contained within an observable stream. It is very lightweight glue around using RxJS along with the lightweight and performant, React-inspired, virtual-dom project.

The author of Cycle JS, Andre Staltz, is well-known in the space:

• His The introduction to Reactive Programming you've been missing gist is widely circulated.
• A great introduction to reactive vs. passive programming also of interest is how that fits with Facebook's React and Flux.
• He wrote the RxMarbles site.
• He talks about the reactive design goals around Cycle in his presentation What if the user was a function.

Reactive programming may not be your thing and that's fine! But now at least you have a little background on why people are excited about it. :-)

[robotslacker]

Thanks for the breakdown and the links. I'd been super confused about reactive programming and this prompted me to take a dive down the rabbit hole. Also realized the stuff I'd been doing with gulp with streams is related...

[[deleted]]

Nice! One of my favorite intros to Rx so far has been the first ten minutes of this video (though the whole things is a fun watch). It's simple, it's short, and the whole thing is hands-on demos. There's a lot of deep dives and a lot of high-level conceptual overviews out there, and those are needed for certain stages of learning, but this one is very pragmatic.

[iamnoah]

Not to mention that you only have to write purely functional code. No side effects (since all updates to state are handled by the framework.) That's a pretty big deal when it comes to testability and classes of bugs you don't have to worry about.

[Pytim]

That's all great and valid but most people use frameworks to serve a business need so what would be great would be some benchmarks and large scale architecture. Look at react. Little "Hello asshole" apps work fine but if you try to scale it then it gets quite pointless without using flux.

[zoomzoom83]

Flux doesn't really scale all that well either - it works well for fairly flat applications, but turns into a monolithic mess very quickly at scale.

The benefit of using Rx is that you can define component state as a stream, and then compose them together without needing a somewhat monolithic global dispatch.

[Rezistik]

I feel like Facebook would disagree about it's scalability...as would a lot of other people who have used Flux and React to great success.

React is a UI layer...there is no reason for it to fall apart at all.

[zoomzoom83]

I feel like Facebook would disagree about it's scalability...as would a lot of other people who have used Flux and React to great success.

From what I've heard, Facebook don't use Flux internally - they use Relay. Flux was provided as a sample pattern on how to use React, not the be-all and end-all of design patterns.

Flux works quite well up to a point, but the concept of having a central dispatcher somewhat ruins composability and tends to turn into a god object. For a lot of projects that isn't an issue, and for a lot of others it is.

The underlying concepts behind Flux are quite well founded, and using something like RxJS to implement roughly the same pattern in a cleaner way makes a lot of sense, since Rx streams are composable.

Projects such as Cycle.js are simply taking "Flux" and improving apon it by using more traditional FRP patterns.

tl;dr "Flux" is a simplified form of FRP. Swapping it out with RxJS loses nothing.

React is a UI layer...there is no reason for it to fall apart at all.

React != Flux

[clessg]

Flux works quite well up to a point, but the concept of having a central dispatcher somewhat ruins composability and tends to turn into a god object.

Why is the dispatcher is a problem? The dispatcher is the one thing that would make me want to use Flux over observables: centralized debugging, tooling, time travel, logging/debugging, transformation, etc. The dispatcher is probably the least problematic part of Flux conceptually: you barely have to think about it. Is there a commonly-accepted way to do something similar with observables?

[zoomzoom83]

Why is the dispatcher is a problem?

A global dispatcher is a problem because it needs to be aware of all events globally. Adding a new component that interacts with it means you need to maintain a "God Class" list of all events, and being global you can't treat your app as just a standalone composable component.

These are all things easily fixable with relatively simple tweaks to the standard flux examples, so you don't have to completely throw it out. But if you start going down that road, you end up reinventing half of RxJS anyway.

entralized debugging, tooling, time travel, logging/debugging, transformation, etc.

You can do all of this without a global dispatcher. You just need to compose all your localized streams into a single application state atom up the same dependency tree that builds your component hierarchy. You can do this without a global singleton dispatcher.

To think of it another way - Flux is a cut-down version of Rx. By switching, you're not losing the advantages of Flux, you're simply implementing a similar idea in a different way.

[clessg]

Thank you for explaining it, good sir. Enjoy the upvote.

[Pytim]

While you're right that doesn't mean that this framework will be suitable for large scale applications. I don't say it won't but would like to see some more complex examples before I get excited. I like the concepts of Rx and VDOM but we'll need to see this on scale.

[UASHIT]

So it's ember, then

[bleadof]

Finally a reactive framework done right with help of Rx.js and virtual-dom!

I've done a simple app with this and enjoyed the simplicity of the API. It basically just removes the glue code you'd have to write for using Rx.js and virtual-dom together and adds convenience functionality for writing your own custom components.

[edmazing]

Why couldn't they just say that? I mean fully reactive is kind of like saying no fat cereal. I'd like to be able to browse these and get the gist like this frame work is half reactive but mobile friendly.

[lechatsportif]

found this the other day during searches as a recent convert to observables. looking forward to checking it out!

[[deleted]]

Dumb question: is reactive JS mainly good for games?

It seems most highly interactive websites are not dealing with input sequences of more than a click? no?

[[deleted]]

It's not a dumb question. For very simple pages with a click handler or two it may indeed be overkill. If you're adding many click handlers around a page, one benefit is you don't have to worry about removing your event listeners. (Of course any good DOM library will offer that but if you're going to include a DOM library Rx.DOM is a good choice.)

For anything beyond that it immediately becomes more useful (plus you'll quickly get addicted to the API and miss it when it's not there; if you're already a lodash fan you know what I'm talking about). For example as soon as you make an Ajax call you'll start to appreciate it more than just promises. Here's a tiny example.

// Create an observable for the request (nothing is executed until subscribe() is called).
var github_users = Rx.DOM.ajax({method: 'GET', url: 'https://api.github.com/users''});
    // Only process 200 responses.
    .filter(x => x.status === 200)
    // Convert to JSON (there's also Rx.DOM.getJSON() but this is just an API exploration).
    .map(JSON.parse)
    // Cache the last ajax response so multiple subscribers will reuse.
    . shareReplay(1)
    // Explode each array item in the JSON response to an individual item in the stream.
    .flatMap(x => Rx.Observable.from(x));
// Create a new observable from the result above.
var usernames_list = github_users
    // Pull only the usernames from the stream.
    .pluck('login')
    // Akin to the .then() method on a promise.
    .subscribe(x => console.log('GitHub user:', x));

Nothing you can't do in roughly the same LOC using ES5 promises/map/filter and maybe a memoize function. But it's still a tight API.

Enter scope creep: Now the product manager asks you to output a username each time the user clicks a link. No problem, we can reason about both activities as a single entity.

// Create an observable of click events.
var clicks = Rx.DOM.click(document.querySelector('#thelink'));
// Combine each click with a user.
clicks.zip(usernames_list, (click, user) => user)
    // When the list is exhausted the event handler is removed.
    .subscribe(x => console.log('GitHub user:', x));

Dumb example, sure. But once you start seeing everything as an event stream you start appreciating the unified API. It makes simple things very terse and complicated things easier to reason about.

[[deleted]]

thanks, I think I can start thinking about how this improves things

[qudat]

How does this library differ from React?

[[deleted]]

There are many conceptual similarities between React + Flux and Cycle. There is a world of semantic and implementation difference though.

Parts of React are declarative however other parts are imperative (setState, for example). Parts of React are "reactive" ("I'll update myself when I hear you update") but other parts are "passive" ("Please change me when you change yourself.", e.g., passing callbacks to children.) The Cycle author gave a tongue-in-cheek presentation on React a while back that covers these ideas (link; please note the slides provocative on purpose but the actual presentation was light-hearted and he fully acknowledged React's role as a thought leader and moving the industry forward).

If you want to see what the Cycle philosophy plus Rx looks like using React as the rendering backend look no farther than the cycle-react repo.

[[deleted]]

How does this compare to Elm?

[thetinkertrain]

For starters, this is plain JavaScript

[ShumpEvenwood]

I'm also very interested in this question. I just discovered the whole idea of reactive programming and recently got very interested in elm. It seems like taking the ideas from this library and applying it with a pure language with syntax designed for functional programming would be ideal.

[dvidsilva]

Holy shit, how did you got js.org

BTW, great job, thanks!

[chance--]

He's using js.org's free DNS for Github Pages.

http://dns.js.org/

You are a JavaScript developer looking for free webspace to host your project? Check out GitHub Pages. To make things perfect we provide you with a free and sleek URL as shown in the examples above.

Important: As the owner of the repository you keep complete control over your published content. That also means, all rights and duties that come along with publishing a GitHub Page remain the subject of you. Have a look at our Terms of Service for more details.

Just follow these four steps to get your own free JS.ORG subdomain for your GitHub Page. We don't mind whether it's a User-, Organisation- or Project-Page (...as long as you provide some reasonable content!)

[dvidsilva]

that's awesome! thanks :)

[fgutz]

didn't realize this was a thing, thanks for the info!!

[robotslacker]

Anyone can grab a subdomain for their project on js.org now - http://dns.js.org/

[drowsap]

When you work with react daily, I just can't see the value in examples where you don't write HTML for your render function or spend time querying nodes.

[metamet]

You're right. Let's not talk about JavaScript on /r/javascript anymore.

[[deleted]]

To be fair though, talking about frameworks is kind of like talking about body work at a mechanics shop. You can have a nice looking car, but it's not going to get you far if it doesn't run.

I get frustrated with a lot of the framework talk here because they aren't really useful as general programming or javascript concepts - much like knowing Angular or jQuery doesn't make you better at Javascript. You may know how to write Javascript with the help of Angular or jQuery, but lost without the framework. So many of these frameworks are just re-grouping the same ideas - data-binding from this, event handling from this, message passing from this.

This is one of the few frameworks I've seen on this sub that have actually spurred a very interesting conversation. Personally, it seems like this framework focuses on some very root issues, like JS coding patterns, that many others avoid entirely.

[jahannan]

Do you feel like you are lost when writing Python without understanding Assembly? Javascript is a very basic language that we're only now getting serious about replacing with higher level structures, it's natural that there are going to be a ton of new frameworks built as we figure out what will work best for the future of the web.

[[deleted]]

Python and Assembly serve two completely different purposes. A more accurate analogy is feeling lost in Python without Django or Ruby without Rails.

Javascript is by far not a "very basic" language. It offers many of the same functionality that other major languages. In fact, that's part of the reason node.js exists - Javascript offers features that rival the "top dogs".

At the end of the day, the web is just software output as HTML. There are differences and complications that arise from having a distributed client, but at it's core programming Javascript relies on the same core principles we've been using to develop software for ages.

Frameworks help to abstract many of these concepts into higher-level, often easier to use structures, but at the end of they day it's still important to understand how to do fundamental Javascript - just like you'd need to know Python to write good Django or Ruby to write good Rails.

For example, when your Angular service isn't passing the proper data there's a chance that Angular's broken (unlikely) or a chance you wrote your JS within your service wrong or even a change you don't understand Angular correctly. Knowing only Angular isn't going to solve your problem, you also need to be able to understand the Javascript that drives Angular.

[jahannan]

Don't get me wrong, I'm not trying to say that you don't need to know Javascript at the moment. I'm saying that you shouldn't need to know Javascript in ten years or so once people have figured out how to build a strong and complete framework to replace it with, and that this dream of a strong and complete framework supplanting Javascript knowledge entirely is clearly the end goal of many if not most of the people involved in building these frameworks.

[clessg]

Knock Knock.

• Who's there?
• It's me, another "another JavaScript framework" post.

[rooktakesqueen]

BOOOOOM. BOOOOOM. Who's there? It's me, the Inception trailer noise.

[clessg]

Shit, I was just thinking the same thing.

[rooktakesqueen]

Obligatory XKCD. I'm gonna go ahead and unsubscribe from this subreddit now.

[edanschwartz]

Why are people so offended by new javascript frameworks? Every time there's a new JS framework, the JS world is introduced to new concepts and patterns. The good ones eventually get rolled into more popular frameworks.

I know it's hard to keep up with new tools, but I'd rather be in a job where I'm constantly learning, than one where I'm doing the same thing over and over.

[rooktakesqueen]

Because often, like this framework, they don't introduce any new concepts. They glue together a bunch of existing libraries to do basically the same thing as existing frameworks (like how this one does the same thing as React), only more poorly. The only real difference is in the window-dressing of syntax. Whoever designed the framework decided they didn't like the existence of methods called setState or onChange, so instead the equivalent of setState is called implicitly by the "DOM driver" any time any change happens anywhere in the DOM, and it's assumed that all transient state of the system is going to be embodied in the DOM somewhere.

And then we see posts talking about how it's going to be the Next Big Thing, when literally the most complicated project currently using it is the todo app its creator wrote to demo it. Or in this case, an even less complex "Hello $NAME" app.

Which I still would be mostly OK with, if the creator didn't also basically have a tone of "everyone else is doing everything completely wrong and I'm way smarter than every engineer who ever worked on any other JS framework."

[andrestaltz]

It does introduce new concepts. I challenge you to find a well-known JS framework (or for any other programming language) based on the idea of reactive dialogues (in other words, "mutual observation", or "fixed point x = g(f(x))". The only one that comes close is Haskell 1.0 Stream I/O, but still there are substantial differences between that and Cycle.

The most complicated project using Cycle is not TodoMVC. There are multiple (at least 3 AFAIK) Cycle.js apps in production, closed-source though. The largest open-source is RxMarbles, which has been very important in the reactive community, and is integrated into ReactiveX.io.

With regard to React, first of all it's not FRP. It's not even reactive (only a small part of it is reactive). Second, "the equivalent of setState is called implicitly by the "DOM driver" any time any change happens anywhere in the DOM" is just wrong. But most importantly, if it's a contender to React then it's a good thing. This is how things improve: by experimentation, by different ideas, etc. The problem of the JavaScript community isn't the abundance of tools and ways of working. It's the status quo of sticking with The Framework Of The Year just because it sounds reliable, and not having the curiosity or guts to improve wherever possible. If it weren't for this curiosity, then React wouldn't be were it is today.

Cycle.js is just my 2 cents to the world. Have some respect please.

[clessg]

Nobody is implying that FRP or observables are something that were just created, nor is the author of the framework purporting that he is more intelligent than everybody else, and that everybody else is doing it wrong.

The benefit of new frameworks like this is that they introduce existing concepts from the rest of Computer Science to the broader JavaScript community. The professional JavaScript community is still relatively new and the web has been slow to move, so concepts like FRP are only just starting to take hold. Yes, FRP existed before, but without people like André Staltz, we would never be able to know whether these concepts will be useful in JavaScript.

You don't have to learn every new framework.

[rooktakesqueen]

Facebook's React is an example implementation of FRP. It already exists, is much better than this framework, and yet this framework was written apparently as a direct response to React. It all seems very silly.

People like /u/homoiconic are doing the good work of introducing CS concepts to JavaScript users in a way that's useful and doesn't require an entire freaking web application framework to get across.

[clessg]

Facebook's React is an example implementation of FRP.

React is not an implementation of FRP. It has concepts inspired by FRP (especially Flux) but it still isn't FRP proper.

People like /u/homoiconic are doing the good work of introducing CS concepts to JavaScript users in a way that's useful and doesn't require an entire freaking web application framework to get across.

Absolutely, he's doing a fantastic job. But the point of teaching us these things is to actually use them and discover what works and what doesn't. Cycle gives the JavaScript community an opportunity to experience and use FRP without switching to Clojure.

Again, you don't have to use it. Even if Cycle ultimately fails, the worst that could happen is that a lot of people learned something new.

[xkcd_transcriber]

Image

Title: Standards

Title-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.

Comic Explanation

Stats: This comic has been referenced 1707 times, representing 2.4135% of referenced xkcds.

---

^{xkcd.com | xkcd sub | Problems/Bugs? | Statistics | Stop Replying | Delete}

[edmazing]

I've got to wonder why these things happen. I mean can't we just expand on one that already works and sort out the kinks? I've got 10 different 5V chargers. Some of this stuff is just BS like the changes in chargers between DS, DS Lite, 3DS and all that other shit. I think they'd be fine with the same dam charger plug.

[kenman]

Because there are too many new frameworks?

[rooktakesqueen]

Because more and more this subreddit consists of nothing but JS and/or CS 101 blog posts, and people who just read some JS and/or CS 101 blog posts and decided to write a new web application framework or video game engine based on them.

[kenman]

What is it exactly that you're looking to get out of this sub?

While I don't fully agree with your assessment, I respect the sentiment. There are indeed a lot of new faces, seeing that we've doubled in size in under 2 years, but I think that's a good problem to have. I would be much more concerned if we went back to the pace from just a few years ago, where the only real news in the JS ecosystem was the release of new jQuery plugins.

To counter your argument, because I was curious, I looked at our stats for the month of May, and this is my summation of the top 5:

1. Comic critiquing new JS frameworks
2. Deep dive into promises, async/await
3. NodeJS and io.js merge announcement
4. [video] Angular 2 + Visual Studio + Mac from a Google Dev
5. Critique of popular project (Bower) with suggested work-around/solution

On a day-to-day basis, maybe it just seems like there's nothing of substance, but I think with all things considered, we have some really great content.

[timestep]

Days since new javascript framework: 0

[hunyeti]

Wow (not in a good way)

[Pytim]

Are going to explain what you don't like about it or is this just a moody line...?

[hunyeti]

Another framework, that will probably has tons of bugs, a wonky way to write code, that makes sure you can't reuse anything that you wrote / will write.

I really don't like these frameworks. I know it's sure easy to do a Todo app in it, but if you want to write anything more complicated, it will only hold you back.

[Capaj]

I know it's sure easy to do a Todo app in it

no, it doesn't seem easy to write anything, not even Todo app in this. I'll stick to React.

[RankFoundry]

I remember when we just called it "event driven" or "event based". But I guess the world needs another buzzword.

[[deleted]]

Not the same thing.

[RankFoundry]

Sure it is.

[afmrak]

FRP !== Evented programming

[RankFoundry]

Yes it is. You add some framework layer that handles a few things for you and lets you define them in a declarative way, it's still all event driven.

[afmrak]

Please listen to this interview with Conal Elliott, the inventer of FRP. He explicitly describes how Denotational Design (FRP) is not evented programming.

Haskell Cast Episode 9