Redux vs RxJS


#1

I have used Redux for some time and have not been that happy with how it is being used with React or other frameworks. I have been looking at RxJS and want to start a discussion around that. Do you have any thoughts on the pros and cons of Redux vs RxJS? I found that RxJS has a better implementation that can scale far better than the one used by Redux although they both are part of the reactive programming movement. :smile:


#2

Its an :apple: :apple: :apple: to :tangerine: :tangerine: :tangerine: comparison. Redux is a state library while RxJS is an async API built around observables. Neither really replaces the other. If you’re looking for an alternative to Redux, something like MobX would be a better comparison.


#3

I know that Redux is a state library and RxJS is a reactive way of doing async. Im not a fan of how Redux is being implemented and want a better reactive way of doing this. Some people have even written their own Redux store with just RxJS and a reducer that saves one store (object). The only disadvantage here is that the store used in RxJS is not immutable like the Redux Store.
I hate that you have to use connect and HOC with Redux and want to have a simpler way of doing the setup.


#4

With hooks (see React Hooks) you won’t have connect and have an hoc anymore. Not sure if something like that would appeal to you more?

Immutability is another thing. It’s not exactly easy to do in JavaScript yet the advantages are certainly there, especially in something like react which checks for changes between values to optimize rendering. But you also have libraries like MobX which don’t use immutability but still get the job done, even in the context of react.

I personally like the ideas behind react and redux, but I agree they’re not great to work with right now. They’re close, and while I like the ideas behind hooks and what they accomplish, it’s also not exactly what I had imagined as the evolution of things here. We’ll see I guess


#5

I have heard of Hooks for sometime but never found the time to get to know them. I will take a look tomorrow. I wish JavaScript was created within a year and not just within a couple of days. The way the frameworks are being used with the language is not elegant.


#6

As much as people like to use it, I don’t think that excuse really holds up :wink: . The goals of JavaScript were pretty clear (despite the Scheme confusion) when it was being designed, and they included being a simple language for the designer types who didn’t want to delve into the complexity of a language like Java (Java at that time). Now people are using JavaScript as they would Java. And its mostly working out, because JavaScript has been constantly evolving since its inception and is capable of a lot more than what it could do in those first 10 days (delete wasn’t even possible until 2 releases after the first). In fact, if you look at newer languages like Swift, you see a tendency for them to look more like JavaScript.

Probably the worst thing about the evolution of JavaScript is the “can’t break the web” philosophy JavaScript has embraced given that it isn’t versioned (in runtimes). This is done on purpose so that web clients wouldn’t have maintain multiple copies of the runtime for all the different versions of JavaScript needed to support what they might encounter in all the sites out there. Its dynamic nature both hurts and helps here, where people can make their own definitions for native objects which could conflict with new features (breaking the web), but it also allows for polyfills for adding features that are “standard” but a certain client might not support yet (and if/when they do, would not differ from the polyfilled implementation causing breakages).

I’d be interested in what you think of hooks. They’re weird, I know. But I think the visualization I posted in the thread I linked above kinds shows some of their benefits. And the talk is worth going through too.