We Compared 13 Top Flux Implementations — You Won’t Believe Who Came Out On Top!

We’ve been using React with and without Flux for a little more than a year at Social Tables. Over this time we’ve implemented many flavors of state management from direct copies of Facebook’s Flux tutorials to weird event-emitting-prop-passed-functions tied to callbacks… :facepalm:. But in the last couple of months the desire to have a standardized methodology for all of our products has grown. So, we decided it was time to sort through the massive list of flux libraries out there, put them to the test, and let the best one win. Here are our results.

We had a specific set of requirements that we were looking for in a library. All of our judgments were made with the knowledge that these needed to be met. That said, if your team isn’t looking for the same things, our results may not be the same.

Our requirements:

  • Popular and well supported
  • Has a dispatcher which prevents multiple events from being dispatched simultaneously
  • Can easily be used with ES5 and ES6
  • Is not tied to React (our main application is a mixture of Knockout and React)
  • Fast (fast enough to allow us to add Flux and React to a Knockout application without any speed degradation)

Flux implementations that made it into our search:

First, we looked at objective measures of popularity and stability. After playing around with a few random Github statistics, a combination of stars, open-to-closed issue ratio, and closed issues per day seemed to provide the most reasonable representation of a library that we would want to use. Together, they do a good job of representing which Flux implementations are interesting to our peers, which ones have a responsive community, and which ones are working toward stability and reliability. There were a few low outliers in the test: Material Flux, Fluxy and OmnicientJS.

At the same time, we were doing quick dives into the documentation and code of some of the others. The first large library to get removed from our search was Reflux. The primary reason we decided to make this switch was because we wanted something that was pure Flux. The language that Reflux used around the dispatcher worried us. We were concerned about how the dispatcher in Reflux might work and were unenthused by the rest of the documentation.

There were few other losses to the popularity battle. Lux, Delorean, and McFly were all outliers in the number of stars and issues they were closing. As cool as their names were, we also dropped them from the search. Sorry Doc Brown.

Another dive into documentation and code happened with our good friend Fluxible. Written by Yahoo, we were pretty confident in the quality and well-supported-future of this library, so it was worth taking time to dive a little deeper. We really liked the ideas behind Fluxible, especially server rendering and dehydration/hydration. However, our app isn’t rendered on the server and it won’t be for a while. Our choice to drop Fluxible was ultimately made because we had some issues with how the API around connecting views to stores works.

At the end of the day, we were left with two: Flummox and Alt. Flummox was heavily inspired by Alt and their implementations have more similarities than differences. We really liked the API provided by both, the FluxComponent provided by Flummox, and the access to snapshotting and bootstrapping that Alt provides.

First run through. Flummox looked pretty incredible.

All else being equal, we care about performance. Enter Flux Capacitor. We wrote a test to hammer each of the flux implementations to find difference in speed. At first glance, the results are pretty unbelievable. Flummox is over twice as fast in all cases. It was so unbelievable in fact, that we didn’t actually believe it. We posted an issue on Alt asking if we did something wrong. We were happy to find out that we did actually do something wrong. In the end, there is no significant difference between the performance of the two implementations.

The fair comparison between Alt and Flummox. Pretty evenly matched.

Which did we choose?

Alt provides

For our set of problems, Alt was definitely the right choice.

See full comparison doc (with less-than-stellar note taking skills) here: https://docs.google.com/spreadsheets/d/1AddJl_vMnCHgdAbabMoIJ087xHuBwJ9jQMfA0mDD_D8/edit?usp=sharing