Nice article, I also use the term es7+ to refer to es7 + pending additions... or es7+stage2 etc, since pretty much anything I care about is at least stage 2 now. The latest being async iterables/generators.
I'm thinking of bumping the major on a few of my modules, and not transpiling for npm, just noting that the features are needed and noting that they should run via babel in any client usage...
It's sad that a post like this is needed... I wouldn't consider doing a modern spa/webapp of even medium complexity without a state machine similar to redux or redux itself. In a team setting it allows you to establish workflows that are consistent and easier to understand.
Also, your reducers and action creators don't need to live together, I tend to import from the base directory into feature based structure/directories. A given directory/feature does not need to contain all of actions(creators), reducers, dumb/smart/pf components and sub-components. But by organizing data/handlers into features and components into features, sometimes in the same directory, it makes it easier to find/discover, though it may seem chaotic at first. Imho, it's better than having to traverse through a deep tree to go from a component to a reducer, etc.
I really like redux, and I'm personally inclined to lean on it, even if it makes the code slightly more complex, that complexity is consistent and easier to follow than just about everything else I've seen.
That said, if you have state that doesn't need to be persisted, then go ahead and keep that at a component level. You can have a higher level component with your actions and setstate, then pass them down to more simple components, or pure view functions.
-- crossposted my comment from HN on the same article.
Nice multi-level router... one nit, don't see redux integration, or event handling in the linked page, will have to look into it. Although redux isn't the only backing solution for react, at this point it's the defacto default.
Oh, I've known quite a few who resisted change... hell, converting ASP.Net apps to use node tools as part of build scripts over the hacky VS plugins was a fight a few years ago... (around node 0.10 release). There are a lot of old timers that resist change, but I've seen relatively young devs (mid 20's) resistant to change as well. I don't think it's really a product of age so much as hitting a point where learning new stuff isn't as appealing.