
Investigating the overhead cost of compiled ES2015 - tilt
https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016
======
bshimmin
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
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)

------
Qerub
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
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
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...](https://github.com/samccone/The-cost-of-transpiling-
es2015-in-2016/pull/12)

~~~
joshschreuder
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
The current state of javascript is to employ 40 tools for build process and
2000 modules to build your product.

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

------
DanRosenwasser
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...](https://github.com/samccone/The-cost-of-transpiling-
es2015-in-2016/pull/18)

~~~
joshschreuder
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?

------
evmar
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...](https://github.com/samccone/The-cost-of-transpiling-
es2015-in-2016/issues/22)

------
pspeter3
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?

