Item — HN Reader

Why? Why should I look at "Modern Redux"? Why wasn't enough thought put in in the original Redux? Like preommr mentioned, the basic flux model isn't that complicated.

Why do you guys complicate things? Why do you think new concepts are required? And new terminology? Why do you write so much code? Why don't you see how these things have been done in the past? This has been done in Mithril for ages.

My suggestion is - next time you guys decide to create something new, don't just keep thinking of new concepts and write code. It's all been done before. Just make it easier to use.

So, no, I'll not be looking at Redux, now or in the future. Because I've got applications to deliver and the end user doesn't give a shit about how fantastic your architecture is, if it takes ages to understand, implement, maintain & debug.

1 comments

> Why wasn't enough thought put in in the original Redux?

Because times change, ecosystems change, patterns change, and user bases change.

Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place?

> Just make it easier to use

And that's exactly what we did :)

"Modern Redux" code is different because:

- We've seen how people have used Redux in practice, what they wanted to do, and what problems they've run into

- We've seen what solutions and other Redux-related libraries the community has invented to solve their problems

- And there's new tools and APIs that have come out since Redux was created, like Immer for immutable updates and React Hooks for writing reusable logic in React components

Like I said, this isn't about "new Redux concepts". It's still state, actions, reducers, dispatching, and subscribing in the UI. It's just much less code to do it, and prevention of common mistakes while using Redux. That means smaller bundles, faster development, and fewer bugs.

This tutorial page shows how Redux Toolkit simplifies all the older Redux logic patterns:

https://redux.js.org/tutorials/fundamentals/part-8-modern-re...

I can't force you or anyone else to use RTK, or to use Redux. If you've got other options that are working for you, please use them.

I'm just pointing out that we _have_ specifically addressed the very concerns you're raising, and if you are genuinely concerned about those issues, you _might_ want to take a look at what we've put together... and I've got a whole lot of enthusiastic RTK users who can vouch for how it's made their development lives and Redux usage experience a lot better.

> Because times change, ecosystems change, patterns change, and user bases change. Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`? Why did C++ add an `auto` keyword? Why is there ever a new version of a language or library? Wasn't enough thought put into them in the first place?

I think the comment you are responding to is a little harsh, but I find this part of your argument disingenuous. JavaScript's syntactic expansion is not definitely a good thing — it isn't all progress.

The rhetorical questions you have presented seem to imply that JavaScript gaining classes is obviously a good thing, whereas I strongly doubt everyone agrees. Did prototypical inheritance work? Yes. Does JavaScript still have prototypical inheritance? Also yes. Is it better to have more choice? Not necessarily. The result of this has been more fragmentation, more documentation, more for beginners to learn, more framework churn, etc.

JavaScript the language was originally invented in just 10 days, and the author himself has explained that aside from the deadline pressure, there are regrettable reasons for the language's inconsistent API.

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

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

That's not what I'm focusing on, and I don't know how you've managed to interpret my comment that way.

In your comment, you said this:

> Why were ES6 classes and hooks invented?

That's why I used classes as a concrete example of the larger point that I was trying to make. My point is that change is fine, but just continually adding stuff to appease people is not necessarily a good thing. All that's happened to JavaScript — as I already pointed out — is the foot-gun now has a wider blast radius and less travel on the trigger.

A perspective from a backend developer who is spoiled from working with very good programming languages:

> Why isn't React still using `createClass()` and mixins? Why were ES6 classes and hooks invented? Why did JS add arrow functions and `async/await`?

Sorry, but all of these are mistakes. I predict that hooks will not survive the battle of time as well as react as a whole will. Arrow functions are mere syntatic sugar, but async/await was a mistake.

Exactly! What's the point of a widescreen monitor if I can't have promises 10 levels deep?

Any half modern language has a syntax construct for it. Unfortunately Javascript is on it's way but not there yet.

I could explain it, but it's already described here better than I could: https://gist.github.com/MaiaVictor/bc0c02b6d1fbc7e3dbae838fb... (scroll to "do-notation")

> Now everything is good and JavaScript is great again, yet I wonder why it took so long

Have you read it? It's saying Javascript has something like that.

No it's not. It is saying Javascript has asnyc/await which is just a specialization of the more general monad-o-syntax (or however you want to call it). And that is precisely what I meant.

The article likes them; you said they're a mistake.