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