23 ms·

> and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-sid That's crazy, y

> and has a start up of 10 seconds to compile via Webpack serverside, or 18 seconds if we're doing it inline via JSPM, and compiling client-sid That's crazy, you should check you're not running more stuff through babel than necessary. (Edit: also why are you compiling via Webpack serverside at all, that sounds like a bad idea)? > I can't wait till browsers have native imports, and support all of ES2016 ... Same except once we have native imports, I'd happily stop with what Chrome has now/then, give up the rest of ES2016 for not having to have a build step for local dev.

dismantlethesun 10y ago
> 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.
- drewgross 10y ago
  > 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). I think you misunderstood. You aren't supposed to run your dependencies through Babel.

dismantlethesun 10y ago

> 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.

drewgross 10y ago
> 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). I think you misunderstood. You aren't supposed to run your dependencies through Babel.