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. 
Its an 
to 
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.
1 Like
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.
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
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.
As much as people like to use it, I donât think that excuse really holds up 
. 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.
