Echo JS 0.11.0

Okay, now add in authentication, client-side routing, menus with security profiles, remote api calls, and a host of other features.

The hoops that you have to learn to get started with react+redux, webpack, babel, node, etc. is still easier than starting a Java application, for example... harder than C#.  Yes, there are tools needed...

I've had to support some pretty big applications with straight JS, and will tell you it's horrible, and doesn't work well at all. You wind up with a lot of troubles, more spaghetti, and even more dead ends, or repeated non-modular code.  The last one took me several hours to fix a bug that would have taken 5 minutes in a more modern JS project structure.

Some people support angular, I prefer react only because there are fewer surprises, and the JSX model is cleaner imho than angular's template dsl.

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.