4 ms·

Investigating the overhead cost of compiled ES2015

83 points by tilt 11y ago

deleted 11y ago
[deleted]
Qerub 11y ago
I had no idea the Closure Compiler supported ES6 until I read this, but then again, it only arrived last May. Here's some more information about it: https://github.com/google/closure-compiler/wiki/ECMAScript6 https://github.com/google/closure-compiler/wiki/ECMAScript6
- xuejie 11y ago
  Me neither! Personally, I would either just use uglify for its speed, or use Closure Compiler since it does much more than just minimizing the source code, to me, Closure forms its own kind of JS compilers. Due to the ES6 drama, I have to live with Babel for now which I really don't like, now I will have to reconsider this whole stack, shame on me that I missed it last May.
kasbah 11y ago
I was just going to comment that it would be interesting to see the size of a run-through with browserify+uglifyify+uglify but looks like there is already a PR for it. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/12 https://github.com/samccone/The-cost-of-transpiling-es2015-i...
- wesleytodd 11y ago
  I just ran that PR and this is what it got: ----------------------------------------- stat -f%z src/dist/bundle.js 15757 gzip -c src/dist/bundle.js | wc -c 4270 ----------------------------------------- So still not quite as small as the rollup, closure, or webpack
- joshschreuder 11y ago
  I'm new to the whole webpack / browserify / etc. stuff, but this seems like a supremely weird build pipeline to me. > When using uglifyify you should generally also use Uglify, to achieve the smallest output. Uglifyify provides an additional optimization when used with Uglify, but does not provide all of the optimization that using Uglify on its own does, so it's not a replacement. Why doesn't Uglify just do all the work and not require a separate component to do extra optimisation? Or is the extra optimisation specifically tailored to browserify?
  - dplgk 11y ago
    The current state of javascript is to employ 40 tools for build process and 2000 modules to build your product.
bshimmin 11y ago
Rollup isn't linked anywhere in this article and I had only dimly heard of it, so here's a link: http://rollupjs.org/ http://rollupjs.org/ I guess it wouldn't be JavaScript without at least three choices, one of them still in its infancy but with features the others don't have, just to make those crucial decisions that little bit juicier.
- joshschreuder 11y ago
  Here's a good comparison table I found (not sure how up to date it is): https://webpack.github.io/docs/comparison.html https://webpack.github.io/docs/comparison.html
wesleytodd 11y ago
The graph there is very misleading because it doesn't use 0 as a baseline. The browserify bundle is only 20% larger than the webpack, but the graph makes it look 5x or so.
pspeter3 11y ago
Modules on the browser also benefit from being scoped appropriately by having a function wrapper. How does "topological sorting of dependencies (ordering the dependencies so that you do not have to worry about import wrapping code)" address that?
DanRosenwasser 11y ago
Hi, member of the TypeScript team here. A big reason for the file size increase seems to be the inclusion of an AMD module loader and AMD prologues themselves. By targeting CommonJS and using Browserify, you see a nice decrease. I've sent out a pull request since finding this. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/18 https://github.com/samccone/The-cost-of-transpiling-es2015-i...
- joshschreuder 11y ago
  I think this puts the TypeScript build 3rd smallest GZIP behind Webpack/Babel/Uglify and Closure. Knowing barely anything about Typescript, does this include TS's ES6 features in the same way as the Babel build?
- deleted 11y ago
  [deleted]
evmar 11y ago
The Closure example failed to pass the compiler flags to minify the code, so the numbers are wrong. At a first glance, the Closure output is about half the size of the numbers published there. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/issues/22 https://github.com/samccone/The-cost-of-transpiling-es2015-i...

83 points by tilt 11y ago

deleted 11y ago

[deleted]

Qerub 11y ago

I had no idea the Closure Compiler supported ES6 until I read this, but then again, it only arrived last May. Here's some more information about it: https://github.com/google/closure-compiler/wiki/ECMAScript6 https://github.com/google/closure-compiler/wiki/ECMAScript6

xuejie 11y ago
Me neither! Personally, I would either just use uglify for its speed, or use Closure Compiler since it does much more than just minimizing the source code, to me, Closure forms its own kind of JS compilers. Due to the ES6 drama, I have to live with Babel for now which I really don't like, now I will have to reconsider this whole stack, shame on me that I missed it last May.

kasbah 11y ago

I was just going to comment that it would be interesting to see the size of a run-through with browserify+uglifyify+uglify but looks like there is already a PR for it. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/12 https://github.com/samccone/The-cost-of-transpiling-es2015-i...

wesleytodd 11y ago
I just ran that PR and this is what it got: ----------------------------------------- stat -f%z src/dist/bundle.js 15757 gzip -c src/dist/bundle.js | wc -c 4270 ----------------------------------------- So still not quite as small as the rollup, closure, or webpack
joshschreuder 11y ago
I'm new to the whole webpack / browserify / etc. stuff, but this seems like a supremely weird build pipeline to me. > When using uglifyify you should generally also use Uglify, to achieve the smallest output. Uglifyify provides an additional optimization when used with Uglify, but does not provide all of the optimization that using Uglify on its own does, so it's not a replacement. Why doesn't Uglify just do all the work and not require a separate component to do extra optimisation? Or is the extra optimisation specifically tailored to browserify?
- dplgk 11y ago
  The current state of javascript is to employ 40 tools for build process and 2000 modules to build your product.

bshimmin 11y ago

Rollup isn't linked anywhere in this article and I had only dimly heard of it, so here's a link: http://rollupjs.org/ http://rollupjs.org/ I guess it wouldn't be JavaScript without at least three choices, one of them still in its infancy but with features the others don't have, just to make those crucial decisions that little bit juicier.

joshschreuder 11y ago
Here's a good comparison table I found (not sure how up to date it is): https://webpack.github.io/docs/comparison.html https://webpack.github.io/docs/comparison.html

wesleytodd 11y ago

The graph there is very misleading because it doesn't use 0 as a baseline. The browserify bundle is only 20% larger than the webpack, but the graph makes it look 5x or so.

pspeter3 11y ago

Modules on the browser also benefit from being scoped appropriately by having a function wrapper. How does "topological sorting of dependencies (ordering the dependencies so that you do not have to worry about import wrapping code)" address that?

DanRosenwasser 11y ago

Hi, member of the TypeScript team here. A big reason for the file size increase seems to be the inclusion of an AMD module loader and AMD prologues themselves. By targeting CommonJS and using Browserify, you see a nice decrease. I've sent out a pull request since finding this. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/18 https://github.com/samccone/The-cost-of-transpiling-es2015-i...

joshschreuder 11y ago
I think this puts the TypeScript build 3rd smallest GZIP behind Webpack/Babel/Uglify and Closure. Knowing barely anything about Typescript, does this include TS's ES6 features in the same way as the Babel build?
deleted 11y ago
[deleted]

evmar 11y ago

The Closure example failed to pass the compiler flags to minify the code, so the numbers are wrong. At a first glance, the Closure output is about half the size of the numbers published there. https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/issues/22 https://github.com/samccone/The-cost-of-transpiling-es2015-i...