Echo JS 0.11.0

The reason to stick with Redux, and related tooling is partially momentum.  It's a nicer/cleaner option imho than say full on flux (and similar), while much nicer as an option than Angular/Angular2, and likely to be able to see corporate buy in.

In the end, you still need to get support from other developers/management/business clients when writing anything, rewriting or changing architectures.

Interesting, though I wish it also supported functions that return a promise... in this way, the resolve action could be the positive result for the worker, and reject could serve as the error result... in this way, async functions could be used.

While I agree with the sentiment... at this point the web development community is already very fractured.  Angular is still very strong in new business development, and React is just starting to edge in.  I'm not suggesting that we stop, but there is merit in sticking with React+Redux for a while.

In terms of features, universal rendering, and hot module replacement are important for iterative development.  React+Redux is at the leading edge of these features, well ahead of many alternatives.  Once the tooling for other options matures, I think it may be worth considering... for now, I'm a cautiously optimistic observer.

I will say there have been far fewer surprises with React+Redux than there have been with options that came before.  I don't mind OO syntax for components, but find that workflows work better in a more functional style.  It just depends on your needs.

Not everybody... plenty of us are using ES6 classes when there is a need for internal/instance state that doesn't need propagation/persistence.

No mention of prototype chains, and property lookup.

Misleading title imho, this shows how to use the cluster module, but not how to deploy an actual cluster in any way.

Regarding babel 6, most new browsers support most features that required transpilation in the box, beyond that, many can be polyfilled dynamically such as via polyfill.io ... 

With that in place, you may not need to enable many ES6/7 features within your bundles/code.  This reduces the load of your application on a client computer.  No need to load code on a client that isn't needed there.

That's the main motivation of babel changing strategies, there have been a lot of requests to have specific packages for different targets... by breaking out the options and targets it allows you to have more options available.

I didn't really read the rest of the rant as many enterprise applications have pre-requisites... setup your database, etc... most npm apps are npm i -g appname, or when you clone from github, npm install... also requiring an appropriate version of node.  Having dockerfile available in the projects helps too.