Echo JS 0.11.0

Should probably add Walmart, I'd be surprised if they, along with GoDaddy are seeing the biggest load under Node today.  When I was at GD, the content service for website builder (published sites end user sees) was seeing something like 300m requests:second and well under 15% load on *many* fewer servers.

Absolutely... And I know there are other, more complex control flow plugins, but I find, similar to redux, that the thunks for action creators is easier to reason with while working on them.

it's looking like yarn mostly wraps or is in addition to npm/node_modules instead of trying to displace it entirely... this I can get behind.  It might be nice to see some of this make it into npm@4/node@8.  Since there will probably be a *lot* of shakeout regarding es6 module syntax in that timeframe.

redux-thunk[0] combined with fetch api[1][2] fits the bill pretty nicely.. even better with async functions for your action creators.

    export const myAction = (param) => async (dispatch, getState) => {
      try {
        dispatch(enableSpinner());
        const result = await fetch('foo');
        const data = await result.json();
        dispatch(dataLoaded(data)); // will disable spinner
      } catch(err) {
        dispatch(generalError(err)); // will disable spinner
      }
    }

[0] https://www.npmjs.com/package/redux-thunk
[1] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
[2] https://www.npmjs.com/package/isomorphic-fetch

I'm disappointed in the number of 0.10, 0.12 and 5.x installs at this point... the upgrades to the next higher version are relatively transparent, and usually within a month most of the binary modules are shaken out.  Moving forward, the most popular modules will be tested during development phase.

Is your site mostly static content with a few one-off bits here and there, it may be more useful than setting up a full-on bundle/build process.

Is your site a green field project where you're going to use modern frameworks or libraries where a bundler is easier to integrate?  In that case, using jQuery is probably a waste over piecemeal options and micro libraries.

Broken on window resize, doesn't scroll overlay space when screen too small for modal.  These happen to be two of the first things I test regarding modals, as they are most often the things that are wrong.

I did a project in ng2 using babel and some of the flow transforms, which worked okay, you definitely need something to handle the decorator syntax as without it, it's *really* not nice to build ng2.  I don't think it was bad, though I did go through growing pains with the router, and even then, it changed again since I had handed off that app around 8 months ago.  Wiring up redux with the router was particularly painful (twice) but syncing the two is really important if you're going to use a redux store at the core of your app state.

From my relatively light exposure, it's really worth digging into Redux for state management, it will make the logic in growing an app much more consistent.  It's not easier than flying by the seat of your pants, but the pain you pay upfront is more than made up for as an app grows.  Beyond this, that workflow can be used with different rendering options from ng2 to react and others...  The ecosystem isn't finished growing and a trend towards web components will probably continue.  Working with unidirectional state management workflows, however is unlikely to go away as it just makes more sense in medium to large complexity apps.  And works well enough in lower to medium complexity.

(my comment, copied from tfa's comments secion)

As much as I like bluebird, there's really no need to polyfill Promises in Node 4+.  Bluebird may well be slightly more well performing in some cases, I don't see that it adds much value, especially since most cases, it will be io bound anyway.  Also, use the mz package and mz/fs for an already async file-system layer.

Also, I'd just assume run my code through babel using one of the modern presets with stage 2 and the decorators transform.  This way I get all the goodies, including async functions with await syntax.  Much cleaner than some of the promise clutter overall.

I agree, tentatively... MY first thought was something decorator based for establishing the class/prototype for validation would be useful.  Though TS specifically wouldn't be necessary, it might be helpful beyond what Babel would offer here, especially wrt child properties as class instances.