Comment by hitekker | Hacker News Reader

Comment by hitekker | Hacker News Reader

Parent Full thread

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.

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

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.

> More worryingly, however, 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?

I found the response to be quite reasonable, and certainly not worrying.

Why would it be a good idea to ignore people that disagree with you? It seems like it would be better to provide rational counter arguments, in the hopes of starting a useful discussion.

I have used Redux on a few projects, largely due to the hype (I.e., good recommendations from others in the community) surrounding it. Without intending to I ran into several discussions on SO and Github where Dan explained why people may not need redux. I think this is a very nice thing, and I think it is unfair to blame Dan or other developers for not reining in the hype more.

I do agree that the title of the article is a bit alarmist and perhaps counter productive.

I will admit to deliberately choosing an _ever_-so-slightly clickbait-y title to get people's attention :) But given the kinds of questions I've seen thrown around, I think it was legitimate as well.

Ignore concerns, not people. And only if those concerns are objectionable and unvalidated by others.

A good example of how to ignore concerns would be comparing Dan's responses here with that of Acemarke's. Dan's is to-the-point and confident, whereas Acemarke's is... markedly less so.

Really, the issue here is not how one developer communicates but how they communicate as a team. It's obvious that this self-damaging article wasn't formally approved by every Redux stakeholder-- but I also recognize that no one on the team expected for this to happen.

I'm very confused by your response here.

I've found a nice niche answering people's questions about React and Redux. I spend a lot of time in the Reactiflux chat channels, as well as a variety of other platforms (Reddit, HN, SO, Twitter, etc). I see questions, my natural impulse is to try to respond and answer them.

Dan Abramov and Andrew Clark created Redux, but now both work at Facebook and are no longer active maintainers. Dan handed over the keys to Tim Dorr and myself. While we don't have any formal division of labor, the typical pattern is that Tim takes care of most of the actual code tasks (merging fixes and publishing releases), and I handle most of the docs stuff and interact with people using it.

None of us have any particular veto over what the others do, and I don't see why I should have "run my post by them" before publishing it.

Yes, the article's tone was defensive, because I've been seeing the same questions, concerns, and FUD get tossed around. So, I was trying to answer those questions and clarify the situation. Most of the feedback I've gotten on the post has been quite positive, along the lines of "Thanks for helping clear that up!".

Maybe responding to you was a bad idea. I dunno. I just get frustrated when I see people complain about things without actually trying to make them better. As my mom told me dozens of times growing up: "You've stated the problem, now state the solution".

So, I'm not "lashing out", and I'm not saying your concerns are "wrongheaded". I'm trying to understand what the actual specifics are that you're concerned about, and find out how we can make things better going forward.

Your response is downright baffling. Really reads like someone in the middle of a manic high, that's how bad you misread the situation.

"Up until recently"

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

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.

And just what exactly is wrong with the TODO example? What's "unintelligible" about it? What do you think would make a better example?

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

Reply on news.ycombinator.com