Flux vs Redux: What are the differences?
"Unidirectional data flow" is the top reason why over 43 developers like Flux, while over 175 developers mention "State is predictable" as the leading cause for choosing Redux.
Flux and Redux are both open source tools. Redux with 49.5K GitHub stars and 12.8K forks on GitHub appears to be more popular than Flux with 16.2K GitHub stars and 3.62K GitHub forks.
According to the StackShare community, Redux has a broader approval, being mentioned in 1036 company stacks & 836 developers stacks; compared to Flux, which is listed in 67 company stacks and 29 developer stacks.
What is Flux?
What is Redux?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Flux?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
We are in the middle of a change of the stack on the front end. So we used Backbone.js with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux.js-style architecture, but with Marionette.
But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.
With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.
Working on a project recently, wanted an easy modern frontend to work with, decoupled from our backend. To get things going quickly, decided to go with React, Redux.js, redux-saga, Bootstrap.
On the backend side, Go is a personal favourite, and wanted to minimize server overheads so went with a #serverless architecture leveraging AWS Lambda, AWS CloudFormation, Amazon DynamoDB, etc.
For IDE/tooling I tend to stick to the #JetBrains tools: WebStorm / Goland.
Obviously using Git, with GitLab private repo's for managing code/issues/etc.
I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.