Alternatives to Redux logo

Alternatives to Redux

Cycle.js, MobX, Flux, React, and RxJS are the most popular alternatives and competitors to Redux.
30.3K
23.1K
+ 1
674

What is Redux and what are its top alternatives?

It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. t provides a great experience, such as live code editing combined with a time traveling debugger.
Redux is a tool in the State Management Library category of a tech stack.
Redux is an open source tool with GitHub stars and GitHub forks. Here’s a link to Redux's open source repository on GitHub

Top Alternatives to Redux

  • Cycle.js
    Cycle.js

    A functional and reactive JavaScript framework for predictable code

  • MobX
    MobX

    MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses. ...

  • Flux
    Flux

    Flux is the application architecture that Facebook uses for building client-side web applications. It complements React's composable view components by utilizing a unidirectional data flow. It's more of a pattern rather than a formal framework, and you can start using Flux immediately without a lot of new code. ...

  • React
    React

    Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project. ...

  • RxJS
    RxJS

    RxJS is a library for reactive programming using Observables, to make it easier to compose asynchronous or callback-based code. This project is a rewrite of Reactive-Extensions/RxJS with better performance, better modularity, better debuggable call stacks, while staying mostly backwards compatible, with some breaking changes that reduce the API surface. ...

  • Apollo
    Apollo

    Build a universal GraphQL API on top of your existing REST APIs, so you can ship new application features fast without waiting on backend changes. ...

  • vuex
    vuex

    Vuex is a state management pattern + library for Vue.js applications. It serves as a centralized store for all the components in an application, with rules ensuring that the state can only be mutated in a predictable fashion. It also integrates with Vue's official devtools extension to provide advanced features such as zero-config time-travel debugging and state snapshot export / import. ...

  • redux-thunk
    redux-thunk

    Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action, or to dispatch only if a certain condition is met. The inner function receives the store methods dispatch and getState as parameters. ...

Redux alternatives & related posts

Cycle.js logo

Cycle.js

10
23
0
A functional and reactive JavaScript framework for predictable code
10
23
+ 1
0
PROS OF CYCLE.JS
    Be the first to leave a pro
    CONS OF CYCLE.JS
      Be the first to leave a con

      related Cycle.js posts

      MobX logo

      MobX

      747
      515
      114
      Simple, scalable state management
      747
      515
      + 1
      114
      PROS OF MOBX
      • 26
        It's just stupidly simple, yet so magical
      • 18
        Easier and cleaner than Redux
      • 15
        Fast
      • 13
        Automagic updates
      • 13
        React integration
      • 10
        Computed properties
      • 8
        ES6 observers and obversables
      • 7
        Global stores
      • 3
        Flexible architecture the requeriment
      • 1
        Has own router package (mobx-router)
      CONS OF MOBX
      • 1
        Maturity

      related MobX posts

      Dan Robinson

      The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

      Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

      #JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions

      See more

      We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux.js inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

      By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.

      See more
      Flux logo

      Flux

      518
      510
      130
      Application Architecture for Building User Interfaces
      518
      510
      + 1
      130
      PROS OF FLUX
      • 44
        Unidirectional data flow
      • 32
        Architecture
      • 19
        Structure and Data Flow
      • 14
        Not MVC
      • 12
        Open source
      • 6
        Created by facebook
      • 3
        A gestalt shift
      CONS OF FLUX
        Be the first to leave a con

        related Flux posts

        Marcos Iglesias
        Sr. Software Engineer at Eventbrite · | 13 upvotes · 223.1K views

        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.

        See more
        React logo

        React

        170.5K
        140.8K
        4.1K
        A JavaScript library for building user interfaces
        170.5K
        140.8K
        + 1
        4.1K
        PROS OF REACT
        • 830
          Components
        • 672
          Virtual dom
        • 578
          Performance
        • 508
          Simplicity
        • 442
          Composable
        • 186
          Data flow
        • 166
          Declarative
        • 128
          Isn't an mvc framework
        • 120
          Reactive updates
        • 115
          Explicit app state
        • 50
          JSX
        • 29
          Learn once, write everywhere
        • 22
          Easy to Use
        • 21
          Uni-directional data flow
        • 17
          Works great with Flux Architecture
        • 11
          Great perfomance
        • 10
          Javascript
        • 9
          Built by Facebook
        • 8
          TypeScript support
        • 6
          Speed
        • 6
          Server Side Rendering
        • 5
          Feels like the 90s
        • 5
          Excellent Documentation
        • 5
          Props
        • 5
          Functional
        • 5
          Easy as Lego
        • 5
          Closer to standard JavaScript and HTML than others
        • 5
          Cross-platform
        • 5
          Easy to start
        • 5
          Hooks
        • 5
          Awesome
        • 5
          Scalable
        • 4
          Super easy
        • 4
          Allows creating single page applications
        • 4
          Server side views
        • 4
          Sdfsdfsdf
        • 4
          Start simple
        • 4
          Strong Community
        • 4
          Fancy third party tools
        • 4
          Scales super well
        • 3
          Has arrow functions
        • 3
          Beautiful and Neat Component Management
        • 3
          Just the View of MVC
        • 3
          Simple, easy to reason about and makes you productive
        • 3
          Fast evolving
        • 3
          SSR
        • 3
          Great migration pathway for older systems
        • 3
          Rich ecosystem
        • 3
          Simple
        • 3
          Has functional components
        • 3
          Every decision architecture wise makes sense
        • 3
          Very gentle learning curve
        • 2
          Split your UI into components with one true state
        • 2
          Recharts
        • 2
          Permissively-licensed
        • 2
          Fragments
        • 2
          Sharable
        • 2
          Image upload
        • 2
          HTML-like
        • 1
          React hooks
        • 1
          Datatables
        CONS OF REACT
        • 41
          Requires discipline to keep architecture organized
        • 30
          No predefined way to structure your app
        • 29
          Need to be familiar with lots of third party packages
        • 13
          JSX
        • 10
          Not enterprise friendly
        • 6
          One-way binding only
        • 3
          State consistency with backend neglected
        • 3
          Bad Documentation
        • 2
          Error boundary is needed
        • 2
          Paradigms change too fast

        related React posts

        Johnny Bell

        I was building a personal project that I needed to store items in a real time database. I am more comfortable with my Frontend skills than my backend so I didn't want to spend time building out anything in Ruby or Go.

        I stumbled on Firebase by #Google, and it was really all I needed. It had realtime data, an area for storing file uploads and best of all for the amount of data I needed it was free!

        I built out my application using tools I was familiar with, React for the framework, Redux.js to manage my state across components, and styled-components for the styling.

        Now as this was a project I was just working on in my free time for fun I didn't really want to pay for hosting. I did some research and I found Netlify. I had actually seen them at #ReactRally the year before and deployed a Gatsby site to Netlify already.

        Netlify was very easy to setup and link to my GitHub account you select a repo and pretty much with very little configuration you have a live site that will deploy every time you push to master.

        With the selection of these tools I was able to build out my application, connect it to a realtime database, and deploy to a live environment all with $0 spent.

        If you're looking to build out a small app I suggest giving these tools a go as you can get your idea out into the real world for absolutely no cost.

        See more
        Zach Holman

        Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

        But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

        But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

        Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

        See more
        RxJS logo

        RxJS

        2.1K
        629
        21
        The Reactive Extensions for JavaScript
        2.1K
        629
        + 1
        21
        PROS OF RXJS
        • 6
          Easier async data chaining and combining
        • 3
          Steep learning curve, but offers predictable operations
        • 2
          Observable subjects
        • 2
          Ability to build your own stream
        • 2
          Works great with any state management implementation
        • 2
          Easier testing
        • 1
          Lot of build-in operators
        • 1
          Simplifies state management
        • 1
          Great for push based architecture
        • 1
          Documentation
        CONS OF RXJS
        • 3
          Steep learning curve

        related RxJS posts

        Eyas Sharaiha
        Software Engineer at Google · | 28 upvotes · 1.1M views
        Shared insights
        on
        TypeScriptTypeScriptAngularAngularRxJSRxJS
        at

        One TypeScript / Angular 2 code health recommendation at Google is how to simplify dealing with RxJS Observables. Two common options in Angular are subscribing to an Observable inside of a Component's TypeScript code, versus using something like the AsyncPipe (foo | async) from the template html. We typically recommend the latter for most straightforward use cases (code without side effects, etc.)

        I typically review a fair amount of Angular code at work. One thing I typically encourage is using plain Observables in an Angular Component, and using AsyncPipe (foo | async) from the template html to handle subscription, rather than directly subscribing to an observable in a component TS file.

        Subscribing in components

        Unless you know a subscription you're starting in a component is very finite (e.g. an HTTP request with no retry logic, etc), subscriptions you make in a Component must:

        1. Be closed, stopped, or cancelled when exiting a component (e.g. when navigating away from a page),
        2. Only be opened (subscribed) when a component is actually loaded/visible (i.e. in ngOnInit rather than in a constructor).

        AsyncPipe can take care of that for you

        Instead of manually implementing component lifecycle hooks, remembering to subscribe and unsubscribe to an Observable, AsyncPipe can do that for you.

        I'm sharing a version of this recommendation with some best practices and code samples.

        #Typescript #Angular #RXJS #Async #Frontend

        See more
        Praveen Mooli
        Engineering Manager at Taylor and Francis · | 19 upvotes · 3.9M views

        We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.

        To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas

        To build #Webapps we decided to use Angular 2 with RxJS

        #Devops - GitHub , Travis CI , Terraform , Docker , Serverless

        See more
        Apollo logo

        Apollo

        2.4K
        1.8K
        25
        GraphQL server for Express, Connect, Hapi, Koa and more
        2.4K
        1.8K
        + 1
        25
        PROS OF APOLLO
        • 12
          From the creators of Meteor
        • 8
          Great documentation
        • 3
          Open source
        • 2
          Real time if use subscription
        CONS OF APOLLO
        • 1
          File upload is not supported
        • 1
          Increase in complexity of implementing (subscription)

        related Apollo posts

        Zach Holman

        Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.

        But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.

        But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.

        Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.

        See more
        Nick Rockwell
        SVP, Engineering at Fastly · | 46 upvotes · 3.6M views

        When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

        So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

        React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

        Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

        See more
        vuex logo

        vuex

        1.5K
        921
        7
        Centralized State Management for Vue.js.
        1.5K
        921
        + 1
        7
        PROS OF VUEX
        • 2
          Debugging
        • 2
          Zero-config time-travel
        • 2
          Centralized State Management
        • 1
          Easy to setup
        CONS OF VUEX
          Be the first to leave a con

          related vuex posts

          Simon Reymann
          Senior Fullstack Developer at QUANTUSflow Software GmbH · | 23 upvotes · 4.8M views

          Our whole Vue.js frontend stack (incl. SSR) consists of the following tools:

          • Nuxt.js consisting of Vue CLI, Vue Router, vuex, Webpack and Sass (Bundler for HTML5, CSS 3), Babel (Transpiler for JavaScript),
          • Vue Styleguidist as our style guide and pool of developed Vue.js components
          • Vuetify as Material Component Framework (for fast app development)
          • TypeScript as programming language
          • Apollo / GraphQL (incl. GraphiQL) for data access layer (https://apollo.vuejs.org/)
          • ESLint, TSLint and Prettier for coding style and code analyzes
          • Jest as testing framework
          • Google Fonts and Font Awesome for typography and icon toolkit
          • NativeScript-Vue for mobile development

          The main reason we have chosen Vue.js over React and AngularJS is related to the following artifacts:

          • Empowered HTML. Vue.js has many similar approaches with Angular. This helps to optimize HTML blocks handling with the use of different components.
          • Detailed documentation. Vue.js has very good documentation which can fasten learning curve for developers.
          • Adaptability. It provides a rapid switching period from other frameworks. It has similarities with Angular and React in terms of design and architecture.
          • Awesome integration. Vue.js can be used for both building single-page applications and more difficult web interfaces of apps. Smaller interactive parts can be easily integrated into the existing infrastructure with no negative effect on the entire system.
          • Large scaling. Vue.js can help to develop pretty large reusable templates.
          • Tiny size. Vue.js weights around 20KB keeping its speed and flexibility. It allows reaching much better performance in comparison to other frameworks.
          See more
          Tim Nolet

          Heroku Docker GitHub Node.js hapi Vue.js AWS Lambda Amazon S3 PostgreSQL Knex.js Checkly is a fairly young company and we're still working hard to find the correct mix of product features, price and audience.

          We are focussed on tech B2B, but I always wanted to serve solo developers too. So I decided to make a $7 plan.

          Why $7? Simply put, it seems to be a sweet spot for tech companies: Heroku, Docker, Github, Appoptics (Librato) all offer $7 plans. They must have done a ton of research into this, so why not piggy back that and try it out.

          Enough biz talk, onto tech. The challenges were:

          • Slice of a portion of the functionality so a $7 plan is still profitable. We call this the "plan limits"
          • Update API and back end services to handle and enforce plan limits.
          • Update the UI to kindly state plan limits are in effect on some part of the UI.
          • Update the pricing page to reflect all changes.
          • Keep the actual processing backend, storage and API's as untouched as possible.

          In essence, we went from strictly volume based pricing to value based pricing. Here come the technical steps & decisions we made to get there.

          1. We updated our PostgreSQL schema so plans now have an array of "features". These are string constants that represent feature toggles.
          2. The Vue.js frontend reads these from the vuex store on login.
          3. Based on these values, the UI has simple v-if statements to either just show the feature or show a friendly "please upgrade" button.
          4. The hapi API has a hook on each relevant API endpoint that checks whether a user's plan has the feature enabled, or not.

          Side note: We offer 10 SMS messages per month on the developer plan. However, we were not actually counting how many people were sending. We had to update our alerting daemon (that runs on Heroku and triggers SMS messages via AWS SNS) to actually bump a counter.

          What we build is basically feature-toggling based on plan features. It is very extensible for future additions. Our scheduling and storage backend that actually runs users' monitoring requests (AWS Lambda) and stores the results (S3 and Postgres) has no knowledge of all of this and remained unchanged.

          Hope this helps anyone building out their SaaS and is in a similar situation.

          See more
          redux-thunk logo

          redux-thunk

          747
          182
          6
          Thunk middleware for Redux
          747
          182
          + 1
          6
          PROS OF REDUX-THUNK
          • 6
            Easy
          CONS OF REDUX-THUNK
            Be the first to leave a con

            related redux-thunk posts

            Choosing redux-saga for my async Redux.js middleware, for a React application, instead of the typical redux-thunk .

            Redux-saga is much easier to test than Redux-thunk - it requires no module mocking at all. Converting from redux-thunk to redux-saga is easy enough, as you are only refactoring the action creators - not your redux store or your react components. I've linked a github repo that shows the same solution with both, including Jest tests.

            See more

            For async requests in React I use redux-saga , to my opinion it is the most organized framework for async requests, it is clearer then redux-thunk and conforms to the style of Redux.js which results in a more structured project, especially in large web applications. #redux-saga

            See more