Investigating the overhead cost of compiled ES2015 | Hacker News Reader

Investigating the overhead cost of compiled ES2015

github.com

83 pointstilt13 comments

Rollup isn't linked anywhere in this article and I had only dimly heard of it, so here's a link: 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.

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

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

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.

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

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

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?

The current state of javascript is to employ 40 tools for build process and 2000 modules to build your product.

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.

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

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?

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

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?

Reply on news.ycombinator.com