> why are you compiling via Webpack serverside at all, that sounds like a bad idea?
Because it turned out to be faster to handle the compile serverside, then use hot-reloading.
Why are we using Webpack? Well because we use ES2016 for everything. I tried cutting down on the # of Babel transforms used, but some Babel plugins rely on the transform output of others (e.g. decorators/static members relies on ES2015 class transform), and so I ended up having to use 80% of all the 'standard' plugins anyways, plus everything up to stage 0.
The alternative was to go down to 3-4 second compile times, by eschewing everything that isn't implemented natively in Chrome. I rejected it as workable because our codebase was already pretty heavily leveraging decorators, but it's something to think about for other projects.
If you only use Chrome implemented features of ES2015, then all you need to make a build is a linker like Webpack/JSPM.
> That's crazy, you should check you're not running more stuff through babel than necessary.
Ah, I think you're saying this because of my 5k line of code figure for the JS project. I'm not counting dependencies... and some of those dependencies are really heavy, made worse because they load incompatible versions of things (e.g. Fbjs 0.13 vs fbjs 0.15).
The same is true for the Python project though, but Python is simply faster at linking pre-compiled files than Babel is. JSPM-client side is worse because it has to load each file individually in the browser and then check to compile it. Loading Babel itself in the browser via JSPM takes like 2 seconds.