5 ms·

Agreed. Half the problem with Redux is technical, the other half is political. Up until recently, the maintainers of Redux have neglected to meaningfully rein

Agreed. Half the problem with Redux is technical, the other half is political. Up until recently, the maintainers of Redux have neglected to meaningfully rein in the hype. If your react app is "complex" and "depending on your usecase"[1], redux must be used. Which is why the very first tutorial in its documentation is a... TODO app. A basic concept deliberately over-engineered to fit a framework that isn't suppose to handle "simple" apps. What? Developer under great social pressure must resolve this glaring dissonance themselves. Developers who may feel more insecure in their knowledge of front-end engineering than they would like to admit. [2] Well, for these developers, it can't be that they're not be "smart" enough. On the contrary, with some mental gymnastics [3], this "smart" framework will solve their "smart" problems, and then they will be "smart". The unspoken corollary is, of course, that anyone who disagrees with the "smart" framework" is not "smart". What begins as misleading by the maintainers creates poison in the enterprise. Suddenly, this popular framework becomes the norm, as team after team is forced to conform, applying this "smart" framework to domains that aren't explicitly forbidden by the docs, to consistently, poor results. Thus the driving force behind Redux became the deep, deep denial of insecure engineers, imprisoned by their own monoliths. Finally, there's a backlash. Without strong-technical-merits or clear-headed communication by the contributors, Redux will likely deflate and be limited to legacy code and the few cases it supports tremendously well. Essentially, for those who've been around the block, Redux is to React what AngularJS 1.0 was to JS frameworks. A shame that we had to suffer through this cycle again. [1] Dev-speak for "If you know what's good for you" [2] As said recently, "Most Developers would not hire themselves" [3] The test for this is if the Redux TODO app makes sense to them.

danabramov 9y ago
"Up until recently" I wrote this a year and a half ago: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
- hitekker 9y ago
  I have respect for your work and your writing. But neither your blog nor the OP's is the source-of-truth. It's the documentation which is why I qualified my statement with "meaningfully". Controlling the hype bubble would have meant rewriting the introduction of the docs, for example, replacing the TODO app with something actually intelligible. This drastic act would also have required buy-in from all the maintainers-- one of whom just posted an article protesting too much the decline of the framework in question. From an outside's perspective, the damage control seems too little, too late.
  - acemarke 9y ago
    And just what exactly is wrong with the TODO example? What's "unintelligible" about it? What do you think would make a better example?
pluma 9y ago
Recently? Dan told people to consider not using Redux as early as 2016: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
acemarke 9y ago
I _completely_ disagree. Dan has spent _far_ more time telling people not to automatically reach for Redux than he _ever_ spent trying to market it. And what other library has ever had to have its maintainers spend more time telling people _not_ to use it, rather than promoting its use? As for the examples: the "TodoMVC" example was already well-established as a common way to showcase JS MVC frameworks by the time Redux came out, so it was a natural choice for the Redux tutorial. We do have several additional examples in the repo, and the "Advanced" docs section builds out a small Reddit client to demonstrate working with async logic. Docs writing is _always_ hard. As Dan originally said when he was writing the docs [0]: > So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”. Now, I'd say that the JS landscape has definitely changed since the docs were written in 2015, and I'm open to ideas for revamping them. But, you also need to illustrate the basic concepts and workflow of a tool without getting bogged down in irrelevant details. Finally... what "domains should be forbidden by the docs"? I've talked to people who have put just a few bits of data into Redux, and others who have opted to put literally _everything_ in their app into the Redux store. Both are viable approaches. Why (and how) should we say "no, don't do X with Redux" that way? If you have specific concerns about the docs, or the way Redux is described and taught, _please_ don't just complain! I'm _always_ open to suggestions for improving the docs and the Redux ecosystem. Please give us some positive contributions and help us make things better for everyone. [0] https://twitter.com/dan_abramov/status/622567874796855296 https://twitter.com/dan_abramov/status/622567874796855296
- hitekker 9y ago
  Have you ever heard of "Negate the frame, Activate the frame"? Well, the headline you chose will hearten the faithful and give pause to everyone else. That plus the defensive tone of the article, sabotages the very framework you're championing. In my opinion, you should have have ran it all by Dan or other maintainers before publishing. More worryingly is your response to the critiques of this thread. If my concerns were so wrongheaded and just so darn disagreeable, shouldn't you have simply ignored them? Or wait and see if they were validated by others? Unless, if course, I'm giving voice to a suppressed thought, something that is already known but refuses to be known. Maybe that would explain the lashing out. I don't know. I just don't have the same emotional investment in Redux. All I'm seeing the same worn-out hype-cycle playing again and again.

danabramov 9y ago

"Up until recently" I wrote this a year and a half ago: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

hitekker 9y ago
I have respect for your work and your writing. But neither your blog nor the OP's is the source-of-truth. It's the documentation which is why I qualified my statement with "meaningfully". Controlling the hype bubble would have meant rewriting the introduction of the docs, for example, replacing the TODO app with something actually intelligible. This drastic act would also have required buy-in from all the maintainers-- one of whom just posted an article protesting too much the decline of the framework in question. From an outside's perspective, the damage control seems too little, too late.
- acemarke 9y ago
  And just what exactly is wrong with the TODO example? What's "unintelligible" about it? What do you think would make a better example?

pluma 9y ago

Recently? Dan told people to consider not using Redux as early as 2016: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

acemarke 9y ago

I _completely_ disagree. Dan has spent _far_ more time telling people not to automatically reach for Redux than he _ever_ spent trying to market it. And what other library has ever had to have its maintainers spend more time telling people _not_ to use it, rather than promoting its use? As for the examples: the "TodoMVC" example was already well-established as a common way to showcase JS MVC frameworks by the time Redux came out, so it was a natural choice for the Redux tutorial. We do have several additional examples in the repo, and the "Advanced" docs section builds out a small Reddit client to demonstrate working with async logic. Docs writing is _always_ hard. As Dan originally said when he was writing the docs [0]: > So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”. Now, I'd say that the JS landscape has definitely changed since the docs were written in 2015, and I'm open to ideas for revamping them. But, you also need to illustrate the basic concepts and workflow of a tool without getting bogged down in irrelevant details. Finally... what "domains should be forbidden by the docs"? I've talked to people who have put just a few bits of data into Redux, and others who have opted to put literally _everything_ in their app into the Redux store. Both are viable approaches. Why (and how) should we say "no, don't do X with Redux" that way? If you have specific concerns about the docs, or the way Redux is described and taught, _please_ don't just complain! I'm _always_ open to suggestions for improving the docs and the Redux ecosystem. Please give us some positive contributions and help us make things better for everyone. [0] https://twitter.com/dan_abramov/status/622567874796855296 https://twitter.com/dan_abramov/status/622567874796855296

hitekker 9y ago
Have you ever heard of "Negate the frame, Activate the frame"? Well, the headline you chose will hearten the faithful and give pause to everyone else. That plus the defensive tone of the article, sabotages the very framework you're championing. In my opinion, you should have have ran it all by Dan or other maintainers before publishing. More worryingly is your response to the critiques of this thread. If my concerns were so wrongheaded and just so darn disagreeable, shouldn't you have simply ignored them? Or wait and see if they were validated by others? Unless, if course, I'm giving voice to a suppressed thought, something that is already known but refuses to be known. Maybe that would explain the lashing out. I don't know. I just don't have the same emotional investment in Redux. All I'm seeing the same worn-out hype-cycle playing again and again.