Closed nolanlawson closed 8 years ago
aww snap :+1: will land this when i update all the graphs at EOD
a wild rando appears
@nolanlawson I'm not super familiar with rollup, but I am with browserify and uglify (and uglifyify). Whats the point in using browserify here? My understanding was that rollup would take es6 code and bundle it - effectively replacing the need for browserify. Would rollup | uglifyjs -c > bundle.js
yield the same outcome but without browserify?
@keithamus I was wondering the same thing myself! Did some digging, and looks like the issue is actually that uglify in this case isn't using --mangle
, whereas uglifyify
does both --compress
and --mangle
by default.
So actually the issue is not Browserify at all; it's uglify. Doing a simple:
rollup -c | uglifyjs --compress --mangle - > ../src/dist/bundle.js
I actually get 3407 bytes, which is even smaller than before. I believe @rich-harris raised a similar point here (https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/17), so I'll just close this and open an issue to add --mangle
to the normal rollup build.
Oh actually, looks like https://github.com/samccone/The-cost-of-transpiling-es2015-in-2016/pull/17 covers all the bases. Carry on! :)
huzzah everyone wins! :dancers:
Thanks @nolanlawson
Adds a new demo:
rollup-plugin-babel-browserify
, using Rollup+Babel as an input to Browserify, as well as the super-helpful kinda-obscure uglifyify transform, which cuts down enormously on the bundle size as opposed to standard Browserify.Using this toolchain, the bundle size is cut down to 3608, which I believe is the smallest one yet in your sample.
uglifyify
is the big hero here; without it, we'd get 4343.Love the demo, by the way! But I think one of the big takeaways is that it pays to really know your toolchain, as well as all the little tips and tricks to squeeze out bytes. :)