If there is one valid criticism of Redux, it is that the names for everything are obtuse and hard to understand.

That, and that the tutorials/beginner-docs don't all start, "look, it's pretty much just two really really simple event dispatchers stuck together, so don't panic" followed by an implementation-focused walkthrough like this.

Redux is way too simple to justify the amount of writing there is trying to teach people to use it[0]. It's two event/message dispatchers. Events/messages move through them thusly. Here's the tiny interface by which you interact with them. Don't do this or this unless you want bugs to happen, and here's why. Done.

[0] a sure sign FP-fans are involved [rimshot]

I couldn't agree more strongly. Something weird happens to FP proponents such that once they get very good at it, they lose all ability to explain or empathize with beginners. :)

One of the most frustrating thing about FP land is that I never feel confident I actually understand anything. Every time I think I might the explanation I arrive at is so damn simple that I can't convince myself it's truly correct because there's this mountain of confusing explanations in my wake, and why would anyone have tried to explain it that way if it were actually this simple?

Docs PRs welcome! :)

(Seriously, I mean it - most of my work as a Redux maintainer has involved improving the docs, and I genuinely am interested in having people help improve them.)

For what it's worth, most of that comes directly from the Flux heritage. For example, the Flux docs at https://facebook.github.io/react/blog/2014/07/30/flux-action... explicitly describe the terms "actions" and "action creators" . There was a lot of discussion and bikeshedding in the early Redux issues over whether to use terms like "events", "commands", or even "facts" instead, but Dan and Andrew opted to keep "actions" for consistency with Flux. (Really, a very large percentage of questions about "Why does Redux do $THING?" can be answered with "Because the Flux Architecture, or other existing Flux libs, did things that way first".)

"Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.

It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :)

It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand.

For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state".

Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.

FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better.

Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.

It's lovely how counterintuitive it is that (in this case) "map" reduces state and "reduce" modifies and/or enlarges state.