I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. The parent comment seems to

I'm afraid that if you're focusing on the technical merits of prototypal inheritance vs classes, you've missed my point completely. The parent comment seems to be arguing that a library or tool should be perfect in its very first release - that the designers should have anticipated every possible use case, target audience, and piece of API design. My point was that _everything_ in technology evolves over time, and Redux is no exception. The Redux core _is_ exceptionally well designed, especially given that Dan and Andrew really only worked on it for a two-month stretch. During that time, they iterated on multiple ideas, particularly the transition from "stores" to "stateless stores" to "reducers", and coming up with the middleware API as a way to allow pluggable side effects logic. Similarly, the design discussion for what became `connect` [0] shows from the very first comment exactly what design constraints were relevant, and while it took some time to nail down the specifics, Dan clearly had the key criteria in mind. At the same time, many of their early ideas about how Redux would be used turned out to be wrong. Dan assumed that people would likely only connect top-level components, and it turns out that connecting many components across the tree is better for performance. Andrew came up with the "Flux Standard Actions" standard, but his idea of having `{error: true, payload: new Error()}` and reusing the same action type for errors and successes has been completely ignored by the ecosystem - it's a lot easier to have separate action types for success and failure. They both thought that thunks were a stopgap that would quickly be replaced by something else, and neither of them could have anticipated the creation of Immer. So, in the real world, no tool is ever designed perfectly from day 1. Requirements change and usage patterns patterns change. That's why libraries and tools publish new versions - to respond to those changing situations. That's why we created and designed Redux Toolkit - to respond to the changes in how people want to use Redux, and the pain points they've experienced using it. [0] https://github.com/reduxjs/react-redux/issues/1 https://github.com/reduxjs/react-redux/issues/1