update JavaScript library practices

[sheppard]

After the 1.0 release, it may be time to revisit a number of decisions related to how wq.apps's JavaScript dependencies are handled. The advantage of the existing "Python-focused" workflow is that it doesn't require npm, and thanks to AMD it works in the browser without building (though see wq/wq-django-template#21). However, these days more and more projects and build tools are moving to npm anyway, and the lack of integration is somewhat inconvenient for experienced JavaScript users.

The post-1.0 decisions include:

• Split out wq/*.js modules into separate npm packages (un-vendor javascripts #66) Mostly Done
• Switch from AMD to ES6 modules using Rollup and/or Babel? Yes
  • Revise/remove https://wq.io/docs/amd? Or keep AMD as the recommended public API but use ES6 modules internally? Yes
  • Integrate Redux for wq/store etc. See redux integration #105
  • Pull out wq/chart.js and wq/pandas.js and make them match d3's plugin spec? Probably
• Switch to npm for managing third party dependencies? (see use official repos for external deps? #1, migrate to more commonly used project tool #2, un-vendor javascripts #66, but also factor out node dependency #14) Mostly Done
• Support (and use) modern/ES6/Harmony features via Babel? (see Deployment script (deploy.sh) fails to optimize ES6 code #83) Yes

The big question is what to do with wq start and the the build system: currently this is all Python except for the r.js optimizer. If wq.app ends up requiring npm it might make sense to move the entire scaffolding tool and build process to npm/JavaScript as well (#2). Another possibility would be to support a dual workflow:

• Python-focused users could install wq.app from a PyPI package which would (still) include all JavaScript dependencies within the package. This version of wq.app could still have end-users import wq/app through AMD and build with r.js. Or we could vendor in rollup/babel instead.
• JavaScript-focused users could install individual wq micromodules from npm. This version would be based on UMD and/or ES6 modules loaded however end-users want to load them (but with a set of default recommendations).

[sheppard]

This is superseded by #111, which assumes the dual workflow option.