Echo JS 0.11.0

Grr.. so sick of seeing variable names like JsonObject, or fooJSON, or "JSON object" in articles... there is no such thing as a JSON object, there are only JSON strings...  For the love of $diety, they are *just* "objects"

Migrating from Browserify to webpack is a really easy move, since webpack supports what browserify does.

I like the approach, especially being that it already has the features I usually have to add with plugins (for redux) anyway.

This kind of flies in the face of the trend to separate stores/state from the components in favor of simpler components...  Also, there's no cleanup of the event registrations which will lead to memory leaks.

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.