Echo JS 0.11.0

How is it any different from any other large development community... take C#/.Net if it weren't for the alt.net crowd and all their work creating frameworks of the day the open-sourcing and great work in ASP.Net MVC never would have happened...  Same goes for Java, Ruby, Python, etc.

If it weren't for prototype, mootools, and a host of other frameworks, we never would have seen jQuery, or gotten to document.query*

It's representative of a healthy ecosystem.  Yes, it makes it harder to get started, but there's always going to be some of that with something new.  JS is far bigger than anything else, just because of how widely it's used/distributed.

Nice entry-level tutorial... misses the use of react-redux for higher-level component integration...  Another useful module is redux-actions (with the S), as well as redux-thunk and some of the other composition support.

I tend to break up my project in terms of feature... that "feature" can consist of multiple marts of components, reducers, actions, api (portion of data access, used with action-creators + redux-thunk).  The features are composed with the type of functionality and grouped hierarchically.  Worried more about structure of features, whether it's for display or data... the data may be used for the display in adjacent features.

If you don't mind a minor lag at startup, and more memory usage, you can `npm install -s babel-cli babel-preset-es2015-node5` and use `babel-node` ... setup a small `.babelrc` file and you're off...

I usually do that at the start of prototyping something in node, often it's "enough" ... I find that async/await is worth it by itself.. add in destructuring, fat-arrow function expressions, and it's really worth it... I'll take easier to reason code with a little tooling over trying to do vanilla node/js these days.

I usually bring up proxyquire when I see someone creating a DI library for JS... for the most part DI libraries aren't needed in JS and only serve to complicate code in ways that isn't needed in practice.

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.